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J^.bstract 


This  bibliography  is  an  outgrowth  of  a  graduate  cour 
Computer  Program  Engineering  and  is  an  attempt  to  provide 
guidance  to  the  literature  in  this  area.  References  annotat 
students  in  the  course  are  provided,  along  with  a  cross  refe 
list  by  topic  area.  This  report  updates  and  supersedes  CSEG- 
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Preface 


Ccniputer  program  engineering  is  a  discipline  directed  to  the 
production  of  computer  programs  that  are  correct,  efficient, 
flexible,  maintainable,  and  understandable;  in  reasonable  time 
spans,  at  acceptable  costs. 

--  J.J.  Horning 


This  bibliography  is  an  outgrowth  of  a  graduate  course  on 
ccmputer  program  engineering  (CS2105)  taught  in  1971  by  W.K. 
McKeeman,  in  1972-1974  by  J.J.  Horning,  and  in  1975  by  D.E. 
Wcrtman.  Students  in  the  course  were  required  to  read  and 
annotate  articles  that  they  judged  appropriate  for  inclusion  in 
the  bibliography,  and  to  indicate  articles  in  previous  editions 
that  should  be  deleted.  These  submissions  were  edited  and 
augmented  by  the  current  editors  and  our  predecessors,  J.E.  Gannon 
and  J.V.  Guttag. 
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The  division  of  the  annotations  into  two  parts  is  an  attempt 
to  reflect  the  rapidly  changing  nature  of  computer  program 
engineering.  All  relatively  recent  articles  are  in  Part  2.  Older 
articles  from  previous  editions  of  this  bibliography  have  been 
carefully  reviewed,  and  many  outdated  entries  have  been  deleted. 
The  remaining  older  articles  constitute  Part  3.  Our  arbitrary 
decision  was  that  articles  older  than  six  years  (1970  or  before) 
would  he  placed  in  Part  3. 


We  encourage  corrections,  new  entries,  and  annotations  from 
all  interested  parties. 
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Hopkins71,  Ichbiah73,  Lyle71,  Manacher71,  Marcotty74, 
Richards69,  Sammet71,  Von  Peschke71,  WegbreitVI,  Wells73, 
Wirth68,  Hirth71b,  Wulf71a,  Wulf71b 


Translator  writing  systems: 

Feldman68,  Gries71,  McKeeman7C 
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Parallel  programming: 

Ashcroft72,  Erinch  Hansen72a,  Erinch  Hansen72b,  Hoare72b 
Prcgrair  construction  aids: 


Ercwn71b,  Eurstall69a,  Euxton70/ 
Flcyd72,  Good70,  Hansen71,  Landy71 
WGgbreit7 1 


Cheatham72b,  Corbin71, 
Manna71,  Snowdon72, 


Language-directed  machine  design: 

Abrams70,  McFarland70,  McKeeman67,  Wortman72 

V •  Correctness ,  Validation ,  and  Debugging 


Highly  recommended: 

Elspas72,  Floyd67, 
Satterthwaite72 


Grishman70,  Hoare69,  Hoare71b,  London70c, 


Papers  referenced  in  this  section: 


Alexander71,  Allen71 
Ercwn73,  Eurstall69a 
Cheatham72a,  Cheatha 
Dijkstra62,  Dijks 

Dijkstra68d,  Dijkstr 
ElspaE71,  Elspas72, 
Gaines69,  Gannon75, 
Gries71,  Grishman70, 
Hoare69,  Hoare71a, 
Horning7Ub,  Kahn71, 
Lassettre72,  LaFran 
London70a,  London70b, 
Manna73,  Miller74, 

Naur69a,  N 
Prokop73 , 
Bust in7 


Morris73d 
Poole73, 
Randell72 
Smith72b , 


Snowdon72, 


,  Ashcroft71,  Erinch  Hansen73a,  Eroo 
,  Eurstall69b,  Eurstall72,  Euxt 
m72b,  Clark73,  Clint72,  Clint73,  Dak 
tra65a,  Dijkstra65b,  Dijkstr 

a71a,  Dijkstra72b,  Dijkstra73,  Donah 
Floyd67,  Floyd72,  Fong73,  Fosdi 
Good70,  Gould71,  Gould73,  Graha 
Gunderman73,  Haney72,  Renders 
Hoare71t,  Hoare72a,  Hoare72b,  Hoar 
King71,  Lampson71,  Lan2aro 
ce71,  Lester71,  Iiskov72,  Disk 
London70c,  London71,  Lucas73,  Man 
Mills73a,  Mills73b,  Morris73a,  Morri 
aur69b,  0gdin73,  Parnas72b,  Parna 
Eain73,  Eamamoorthy75 ,  Bande 
Sa tterthwaite72 ,  Schneiderm 
Vander  Noot71,  Wegbreit71,  Yohe74 


ks75, 
on70 , 
in73  , 
a68c , 
ue75 , 
ck72  f 
m73b, 
on7  2 , 
e72c , 
ne72 , 
ov7  3 , 
na7 1  , 
s73c , 
s72f , 
1171  , 
an73  , 


Reliability : 

Euxton70, 
Dcnahue75 
Lampson7 1 
Naur6  9b, 
Randell72 


Clark73,  Dijkstra62,  Dijkstra68d, 
Elspas71,  Gannon75,  Hoare72a, 
Liskov72,  Liskov73,  Miils73b,  Morris73c, 
Ogdin73,  Parnas72f,  Ramamoorthy75 , 
Schneiderman73 


Di jkstra71a, 
Horning74b , 
Morris73d , 
Randell7 1 , 
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Validation : 


Erook  =75 , 
Di jkstra62 
Elspas72 , 
Hcare72b, 
Mills73ar 
E  ustin71 , 


Erown73,  Euxton70,  Cheatham72a,  Cheatham72b 
,  Dijkstra65a,  Eijkstra68c,  Dijkstra72b,  Elspas71 
Floyd72,  Fosdick72,  Hoare71a,  Hoare71b,  Hoare72a 
Kahn71,  Lanzarone72,  Liskov72,  London70a,  London70b 
Morris73d,  Poole73,  Prokop73,  Eamamoorth y75 

WGgbreit7 1 


9 


9 

9 

9 


Correctness  -  formal  approaches: 


Allen71, 
Clint72 , 
Gccd7  0 , 
HoarG72c, 


Ashcroft71,  Eurstall69a,  Eurstall69b,  Eurstall72, 
Clint73,  Dijkstra73,  Eispas72,  Floyd67,  Floyd72, 
Hoare69,  Hoare71a,  Hoare71b,  HcarG72a,  Hcare72b, 
King71,  Manna71,  Manna73,  Morris73a,  Eustin71 


Correctness  -  informal  approaches: 


Dijkstra65a,  Dijkstra65b,  Dijkstra68c,  Dijkstra68d, 
Dijkstra71a,  Dijkstra72b,  Elspas72,  London70c,  iondor.71, 
NaurSSa,  Smith72b,  Snowdon72 

Testing: 

AlGxander71,  Erinch  Hansen73a,  Brooks75,  Erown73,  Euxton70, 
Gould71,  Haney72,  Lucas73,  Mills73b,  Parnas72t,  Foole73, 
Rain73,  Vander  Noot71 


Automatic  generation  of  test  cases: 

Elspas71,  Gould71 
Debugging : 

Erown73,  Euxton70,  Dakin73r  Fong73,  Gaines69,  Gould73, 
Grishman70,  Gunderman73,  HenderEon72,  Lassettre72,  LestGr71, 
Miller74,  Cgdin73,  Poole73,  Fain73,  Eustin71,  Satterthwai te72 , 
Yche7  4 

Syntax  error  recovery: 

Graham73b,  Gries71,  LaFrance71 
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VI.  Evaluation 


Highly  recommended: 


Parnas67 


Papers  referenced  in  this  section: 

Alexander71,  Arden69,  Arv€y73,  Eard71,  Bard72,  Eard73, 
Euxton70,  Cheatham72b,  Cohen74,  Cumming7l4  Dakin73,  Deutsch72, 
Graham71,  Graham73a,  Hatfield71,  Kimbletcn72,  Lassettre72, 
Lucas71,  Lucas73,  Margolin72,  Miller72,  Naur69b,  Nemeth7l, 
Parnas67,  Eandell71,  Eustin71,  Weiderman71,  Wortman72 

Evaluation : 

Alexand€r71,  Arvey73,  Euxton70,  Cheatham72b,  Cohen74, 
Cumming71,  Kimbleton72 ,  Lucas73,  Miller72,  Randell71, 
Wortman72 


Modelling : 

Bard72,  Lassettre72,  Margolin72 
Simulation : 


Graham71,  Graham73a 

Monitoring : 

Arden69,  Eard71, 
Hatfi€ld71-  Lucas71 


Parnas67,  Rustin71 


Eard73,  Cumraing71 
Naur69b,  Nemeth71 


Weiderman7 1 


Cakin73,  Deutsch72 


VII.  Eocument ation 


Papers  referenced  in  this  section: 


Auerbach72 
Erooks75, 
Mills7C, 
Sccwen7 1 , 


,  Eelady71 
Fosdick72 , 
Mills73b, 
Simmons72, 


,  Erinch  Hansen73a,  Erown74,  Erophy70 
Habermann73,  Kerpelman71,  Maynard72 
Naur69b,  Parnas72e,  Pearson73,  Poole73 
Van  Buyn72,  Watkins73 


r 


9 
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VIII.  Miscellaneous 


Highly  reccmmended : 

Cheatham72t 

Papers  referenced  in  this  section: 

Arden72,  Eauer73,  Euxton70,  Euxton71,  Cheatham72b, 
Ccnstantin€68 ,  Corbin71,  Hclt73a,  Parnas72a,  Parnas72d, 
Shaw72,  Weinberg71 

Education : 

Eauer73,  Euxton70,  Euxton71,  Constantine68 ,  Corbin71,  Holt73a, 
Parnas72a,  Parnas72d,  W€inberg71 

Laboratories: 

Arden72,  Euxton70,  Cheatham72b,  Corbin71,  Parnas72d,  Shaw72 
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;^,LEX;^.NCEE71 

Alexander,  W.G,;  How  a  Programniing  Language  is  Used;  Technical 
Peport  10,  Computer  Systems  Eesearch  Group,  University  of  Toronto 
(Eebruary  1972)  pp. 1-119. 

An  analysis  tool  is  discussed  and  developed  with  which  an  XPL 
programmer  may  determine  the  status  and  dynamic  usage  of  time  and 
the  distribution  of  machine  instruction  usage  for  his  XPL  program. 
Although  limited  in  its  scope  to  one  language  it  is  a  good  example 
of  the  type  of  low  level  analysis  technigue  that  could  profitably 
be  applied  tc  any  large  programming  project  tc  pinpoint 
unsuspected  inefficiencies.  The  particular  implementation  used  i 
slow  because  it  relies  upon  operating  system  interrupts  an 
recoveries  but  does  produce  comprehensive  (although  not 
selectively  ccntrolled)  data  analysis. 


ALLEN71  CE22,683 
Allen,  C.E.;  The  Application  of  Formal  Logic  to  Programs  and 
Programming;  IBM  Systems  Journal  10,  1  (January  1971)  pp,2-38. 

A  hierarchical  application  of  first-order  predicate  calculus  is  a 
practical  solution  for  proving  the  correctness  of  programs.  Allen 
first  gives  a  brief  introduction  to  formal  logic,  and  then 
develops  the  results  of  Manna  and  Ashcroft  on  an  elementary  level. 
Finally  he  presents  some  examples  and  theories  of  his  own  as  well 
as  some  applications  of  the  proof  techniques. 


AEtEN72  CR25,286 
Arden,  E.W.,  Flanigan,  L. K. ,  and  Caller,  E.A. ;  An  Advanced  System 
Programming  Course;  Proceedings  of  IFIP  Congress  71  (1972) 
pp, 1510-1514. 


AEVEY73 

Arvey,  R.D.,  Hoyle,  J.C.;  Evaluating  EDP  Personnel;  Datamation 
19,7  (July  1973)  pp. 69-73. 

One  of  the  major  problems  in  undertaking  a  project  to  produce  a 
large  program  is  the  reliability  of  the  personnel  involved.  The 
manager  of  such  a  project  must  have  information  about  the 
abilities  of  the  analysts  and  programmers  in  order  to  make  any 
intelligent  attempt  at  work  allocation  and  scheduling.  The  author 
discusses  his  experiences  in  tackling  this  problem  and  suggests 
avenues  of  approach  that  a  manager  faced  with  this  problem  could 
investigate . 
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ASHCE0FT71  CR21,9aO 
Ashcroft,  E.A.,  and  Manna,  Z. ;  Formalization  of  Properties  of 
Parallel  Programs;  Machine  Intelligence  6,  Edinburgh  University 
Press  (1971)  pp. 17-42. 

This  paper  provides  a  very  instructive  introduction  to 
possibilities  for  applying  formal  proof  techniques  to  parallel 
programs.  The  first  section  consists  of  a  definition  of  what  will 
be  considered  a  parallel  program;  it  may  contain  simple 
assignment  statements,  test  statements,  (possibly  recursive) 
process  calls,  and  blocks  defining  parallel  branches.  In  this 
context  the  properties  of  a  "computation,"  and  the  possible  ways 
of  terminating  parallel  segments  are  discussed. 


It  is  shown,  by  example,  how  a  parallel  program  may  be  transf 
into  a  non-deterministic  program,  which  is  the  basis  for 
desired  formalization.  Also  presented  at  this  stage  ar 
possible  ways  of  defining  "protected"  sections  of  programs, 
are  required  for  the  subsequent  simplification  methods. 


ormed 
the 
e  the 
which 


Properties  which  programs  may 
in  the  development  of  a  formal 
program  are  explained,  using  a 


have  are  enumerated,  and  the  stages 
statement  of  the  properties  of  a 
specific  example. 


The  last  major  section  describes  method 
simplification,  based  on  the  detection  of  instanc 
computation  of  a  program  is  independent  of 
execution  of  parallel  segments,  thus  reducing  the 
cases  for  which  formulae  must  be  derived. 


s  for  pr 
es  in  which 
the  sequen 
total  numbe 


ogra  m 
th  e 
ce  of 
r  of 


The  paper  concludes  with  suggestions  of 
features  which  might  be  considered  in  similar 


additional 
fashion . 


program 


ASHCPCFT72  CB24,932 
Ashcroft,  E. ,  and  Manna,  Z. ;  The  Translation  of  "go  to"  Programs 
to  "while"  Programs;  Proceedings  of  IFIP  Congress  71  (1972) 
pp. 250-255. 


This  paper  demonstrates 
translated  into  an  equi va 
proves  that,  in  genera 
preserve  certain  values  o 
of  computation. 


that  every  flowchart  program  can  be 
lent  "while"  program  without  "go  to"s  and 
1,  new  variables  must  be  introduced  to 
r  information  which  reflects  the  course 


AUEEEACH72 

Auerbach;  Documentation  Aids;  Auerbach  Standard  EDP  Reports; 
Auerbach  Info,  Inc.,  no.  8  (1  972)  . 


This  is  an  extensive  and 
documentation.  Various  uses 
planning,  implementation  and 
elements  of  documentation  (e.g., 
program  description,  equipment 
enumerated  and  justified.  Since 


essentially  complete  survey  of 
of  documentation  during  project 
maintenance  are  described.  The 
history  and  status,  glossaries, 
and  software  environment)  are 
Auerbach  is  essentialy  a  software 
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products  handbook,  the  main  focus  of  the  paper  is  on  what 
automatic  documentation  can  and  should  dc  fcr  a  program.  The 
capabilities  of  text  and  comment  processing,  intention  abstraction 
and  graphical  flowcharting  or  paragraphing  are  investigated  in 
relation  to  the  components  of  a  program.  The  component 
descriptions  discussed  are  functional  relations,  data  bases,  files 
and  tables. 


AVCTS73 

Avots,  J.;  Making  Project  Management  Work;  Datamation  19,1 
(January  1973)  pp. 42-45. 

The  article  discusses  the  human  and  technical  factors  (emphasizing 
the  former)  that  contribute  to  the  success  of  a  large  systems 
project.  Many  management  tools  for  project  scheduling  and 
reporting  are  available  or  may  be  developed.  Fcr  large  projects 
they  will  be  computer-based.  However,  participation  in  planning 
and  a  common  understanding  of  procedures  and  goals  by  all  project 
members  is  essential  in  order  to  sustain  the  necessary  enthusiasm 
and  co-operaticn . 


E;iKEE72a  CR 2 3 , 1  13 ;  2 4 , 65 3 
Baker,  F.T.;  Chief  Programmer  Team  Management  of  Production 
Programming;  IBM  Systems  Journal  11  ,1  (1972)  pp. 56-73  . 

This  paper  combines  an  enunciation  of  the  principles  involved  in 
chief  programmer  team  organization,  and  the  problems  which  the 
approach  is  intended  to  solve,  with  a  description  of  how  the 
method  was  applied  to  a  particular  project:  an  information  bank 
system  for  the  New  York  Times.  The  general  specifications  for  the 
system  are  described,  and  an  outline  of  the  stages  of  development 
of  the  implementation  is  given,  to  demonstrate  the  correlation  of 
the  team  structure  with  the  way  in  which  the  problem  was  broken 
dcwn  and  solved.  Statistics  are  given  to  indicate  how  the  various 
team  members  spent  their  time.  The  paper  concludes  with  a  review 
of  the  benefits  obtained  by  the  chief  programmer  team  approach  to 
the  project. 


EAKEE72b  CR25,203 
Eaker,  F.T.;  System  Quality  Through  Structured  Programming; 
Proceedings  of  the  FJCC  41  (1972)  pp. 339-344. 

An  interesting  addition  to  the  literature  concerning  chief 
programmer  teams,  this  article  reiterates  the  principles  behind 
their  organization.  None  of  this  material  is  really  new,  but  the 
author  does  cite  some  previously  unpublished  statistics  obtained 
from  the  New  York  Times  information  bank  project.  The  figures 
indicate  the  numbers  of  errors  of  various  types  which  occurred  in 
various  parts  of  the  project.  Baker's  analysis  of  the  information 
supports  the  idea  that  rigorous  adherence  to  the  principles  of 
chief  programmer  teams  results  in  considerably  reduced  testing 
times  and  error  occurrences  after  product  delivery. 
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CR25,352 
Bulletin,  16,11 


Ef.KEE72c 

Baker,  P.A.;  Hew  to  Write  Systems;  Computer 
(November  1972)  pp.53U-536. 

P.  humorous  look  at  avoiding  all  real  problems,  writing  "friendly" 
code,  and  muddling  through  the  middle  of  the  project  on  the  way 
from  the  end  to  the  beginning.  The  module  decomposition  criterion 
of  Parnas  reappears  with  the  words  "put  the  code  least  likely  to 
succeed  off  by  itself.  Remember  that  you  will  be  back  again." 


E;^KEB73 

Baker,  F.T.,  Mills,  H.D.;  Chief  Programmer  Teams;  Datamation  19,12 
(December  1973)  pp. 58-61. 

The  authors  assert  that  the  main  occupations  of  programmers  in  the 
traditional  management  structures  are  debugging  and  clerical 
chores.  The  chief  programmer  team  concept  is  presented  as  a  tool 
by  which  the  efforts  of  the  programmer  are  channeled  into  the 
tasks  of  design  and  programming  rather  than  debugging.  Integral 
to  this  concept  is  the  practice  of  structured  programming. 

The  authors  give  a  very  detailed  description  of  the  chief 
programmer  team  and  its  implementation,  drawing  on  considerable 
experience  to  illustrate  their  points. 


E;^LZER71a 

Ealzer,  E.M.;  PCETS 
Communication  and  Job  C 
pp. 485-489 . 

As  an  extension  of  Datal 
freely  interchange  phys 
programs,  and  a  monitor  a 
By  using  PCETS  and  a  set 
SEND,  RECEIVE,  CCNDITIO 
RECUEST,  modules  may  be  r 
"monitor  modules"  may  be 
of  two  or  more  components 
in  terms  of  his  In ere 
uses  an  extension  of  Dijk 


A  Method  for  Dynamic  Int 
ontrcl;  Proceedings  of  the  SJCC 


ess  Programming,  one  should  be  a 
ical  devices,  terminals,  file 
s  the  object  of  a  specific  commu 
of  commands  such  as  CONNECT,  DI 
NAL  PECEIVE,  REQUEST,  and  CO 
econnected  in  alternate  configur 
incorporated  between  the  input  a 
of  the  system.  Ealzer  explains 
mental  Systems  Programming  Langu 
stra's  semaphores. 


CR22,799 
erpr  ogra  m 
38  (1971) 


llowed  to 
s,  other 
nica tion . 
SCONNECT , 
NDITIONAL 
ations  or 
nd  output 
his  ideas 
age  which 


EALZEB71 b 

Ealzer,  E.M.;  On  the  Future  of  Computer  Program  Specification  and 
Organization;  Rand  Corporation,  Santa  Monica,  Cal.,  no. E-622-ARPA 
(August  1971)  pp.1-23. 

EAED7 1 

Sard,  Y.;  CP-67  Measurement  and  Analysis;  Proceedings  of 

ACM/SIGOPS  Workshop  on  System  Performance  Evaluation  (April  1971). 

and  measurement  technigues  used  to 
CP-67  with  respect  to  throughput. 


Discusses  the  statistical 
compare  various  releases  of 
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overhead,  etc.  This  paper  is  interesting 
67  is  an  easy  system  on  which  to  perform 
free  measurements.  Additionally,  the  appl 
this  and  a  prior  study  led  to  a  re-design 
dramatic  improvement  in  performance. 


for  several  reas 
relatively  inte 
ication  of  the  r 
of  some  modu 


ons,  CP- 
rf er ence- 
esults  of 
les  with 


EAEC72 

Eard,  Y. ,  and  Sur yanarayana ,  K.V,;  On  the  Structure 

Overhead;  in  Freiberger,  W.  (ed.).  Statistical 
i^lfoiSMce  Evaluation,  Academic  Press  (1  972). 


of  CP- 6 7 
Computer 


Regression  analysis  lives  again 
annals  of  IEM*s  history.  Still,  it 
actual  software  bottlenecks,  and 
efficient  real-time  programs  should 
the  uses  of  the  technique. 


in  this  thrilling  tale  from  the 
*s  a  good  way  to  determine 
those  concerned  with  producing 
probably  te  acquainted  with 


E^ ED73 

Eard,  Y. ;  Experimental  Evaluation  of  System  Performance;  IBM 
System  Journal  12,3  (1973)  pp. 302-314. 

The  paper  reports  on  a  method  for  testing  system  performance, 
developed  to  be  used  as  part  of  an  evolutionary  operation 
technicue  to  improve  systems. 

The  performance  of  different  features  of  the  system  are  tested  by 
using  rapid  on-line  switching,  as  opposed  to  conventional  day-by¬ 
day  switching,  of  the  various  versions.  This  technique  of  on-line 
switching  has  been  used  successfully  to  test  a  paging  replacement 
algorithm,  various  time-slicing  constants  and  the  effect  of 
assigned  priorities  on  the  user  in  a  time  sharing  system. 


EARTH74 

Earth,  C.W,;  Notes  on  the  case  Statement;  Software  -  Practice  and 
Experience  4,3  (July-September  1974)  pp. 289-298. 


A  brief  examination  of  the  history  of  the  case  stat 
introduced  by  Hoare  and  Wirth.  The  paper  touches  on  the 
of  the  earlier  version  and  their  solution  in  the  later 
and  culminating  in  yet  another  "natural  and  intuitive" 
extension  to  facilitate  "structured  programming"  (comp 
backwards-spelled  bracketting) .  The  author  proposes 
conditional  test  (Boolean  expression)  form  of  case, 
syntax  to  make  explicit  the  semantics  of  an  "out-of-ran 
(i.e.,  whether  "no-operation"  or  "error"  is  to  res 
readable  but  only  barely  informative  article  for  light 
reading . 


ement,  as 
problems 
versions , 
language 
lete  with 
(a)  a 
and  (b)  a 
ge"  case 
ult)  .  A 
be  dtim  e 


EAUER72 

Eauer,  F.I.;  Software  Engineering; 
(1972)  pp. 530-538. 


Proceedings  of 


CE25,047 
IFIP  Congress  71 
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A  definition  of  the  term  "software  engineering"  is  given  as  "the 
part  of  computer  science  which  is  too  difficult  for  the  computer 
scientist."  The  aims  of  software  engineering  are  discussed,  along 
with  reasons  for  adopting  these  aims,  and  the  problems  involved  in 
meeting  them.  The  role  of  education  in  the  introduction  of 
software  engineering  techniques  to  the  programming  community  is 
mentioned,  and  the  resultant  obsolescence  of  present  prcgramming 
techniques  is  predicted.  Problems  involved  in  applying  techniques 
of  industrial  engineering  to  software  are  explored,  and  solutions 
fcr  some  are  offered.  The  role  of  structured  programming  as  a 
tcol  for  application  of  those  techniques  is  investigated  at  some 
length,  and  some  problems  not  solved  by  this  tool  are  examined. 
The  concluding  remarks  present  some  ramifications  of  the 
techniques  and  philosophy  of  software  engineering  for  the 
programming  community,  and  point  out  the  need  for  comparative 
testing  and  more  widespread  discussion  and  use  of  these  points  in 
order  to  achieve  progress  in  the  field. 


E?UEE73  CE26,197 
Eauer,  F.L.;  Software  and  Software  Engineering;  SIAM  Review  15,2 
part  2  (April  1973)  pp. 469-480. 

This  is  a  survey  paper  on  software  engineering.  It  is  discussed 
under  the  following  four  headings;  (1)  how  the  term  "software" 
developed;  (2)  how  software  was  (and  still  is)  developed;  (3)  how 
software  should  be  developed;  (4)  how  software  engineering  should 
develop  in  the  future.  Under  (1)  and  (2)  a  brief  history  of 
software  and  its  relation  to  computing  is  given  all  the  way  back 
tc  Eafcbage.  Under  (3)  the  software  crisis  is  analysed  and 
suggestions  for  its  mastery  are  given.  Finally  under  (4)  the 
problems  of  educating  the  next  generation  of  programmers  are 
discussed . 


EEIADY71 

Eelady,  L.A.,  and  Lehman,  M.M.;  Programming  System  Dynamics  or  the 
Meta-r ynamics  of  Systems  in  Maintenance  and  Growth;  IBM  Research 
Center,  Ycrktcwn  Heights,  no.  EC3456  (September  1971). 

A  model  is  developed  for  large  programming  systems  in  which 
continuous  repairs  and  enhancements  occur.  This  primary  effort 
leads  to  fragmentation  of  the  system  and  of  the  repairs  and 
enhancements,  and  is  shown  to  be  linearly  bounded  by  cost. 
However,  a  secondary  and  exponential  effort  shows  up  because  of 
correlation  between  fragments,  communications  among  others  working 
in  parallel,  and  maintenance  of  documentation.  There  is 
initially,  in  practice,  a  decay  in  the  secondary  effort  due  to  the 
initial  accuracy  and  correctness  of  the  system;  however,  the 
authors  believe  this  is  only  temporary  in  nature,  i.e.,  the  effort 
tc  maintain  the  resultant  work  is  itself  always  exponential  due  to 
the  same  factors. 

Ey  identifying  these  linkages  of  communications  and  maintenance  as 
critical  points  the  authors  feel  that  a  "programming  system 
development  methodology,"  which  includes  the  elimination  of  global 
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variables  and  adopting  unspecified  but  reasonable  standard 
documentation,  is  essential.  Since  they  believe  the  expone 
term  never  vanishes,  their  objective  is  to  delay  the  expl 
cost  growth  of  maintaining  large  systems.  As  a  result  the  pr 
reguirement  is  "to  guantify  complexity  of  growth  measures... 
plan  precisely  for  the  development,  maintenance,  growth 
ultimate  termination  of  a  system,  and  its  replacement." 
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EENSON73 

Eenson,  J.P.;  Structured  Programming  Techniques;  IEEE  Symposium  on 
Computer  Software  Eeliability,  New  York  (April  1973)  pp. 143-1 47. 

The  paper  attempts  to  answer  the  question  "What  is  structured 
programming?"  by  examining  the  different  meanings  which  have  been 
associated  with  the  term.  Structured  programming  is  viewed  as  a 
design  methodology  by  examining  the  work  of  E.W,  Eijkstra  and 
H.D.  Mills.  It  is  viewed  as  a  coding  technique  (gotoless 
programming)  in  the  light  of  the  work  by  Eohm  and  Jaccpini.  The 
paper  serves  as  a  good  (and  brief)  introduction  to  the  major  ideas 
of  structured  programming. 


EEEGEP0N71 

Eergeron,  E.D.,  Gannon,  J.D.,  and  van  Dam,  A.;  Language  for 
Systems  Development;  SIGPLAN  Notices  6,9  (October  1971)  pp, 50-72. 


EICOM75 

Eloom,  A.M.;  The  "ELSE"  must  go,  too;  Datamation  21,5  (May  1975) 
pp.  123-126. 


Eloom* s  thesis  is  that  the  use  of  multiply- 
grcups  leads  to  the  production  of  programs  whic 
hard  to  maintain,  since  it  is  difficult 
conditions  under  which  a  given  section  of  code 
the  processing  associated  with  an  ELSE  clau 
that  of  an  IF  (NOT) -THEN  which  specifies  the 
original  IF  condition,  the  ELSE  is  actually 
advocates  the  use  of  "functional"  progra 
preparation  of  a  decision  table  indicat in 
conditions  under  which  specific  functions  are 
followed  by  direct  coding  from  the  table 
disadvantages  of  ceding  duplication  and  run-tim 
outweighed,  it  is  claimed,  by  the  more  eco 
debugging  and  maintenance  ease. 


nested  IF-THEN-ELSE 
h  are  complex  and 
to  see  the  specific 
is  executed.  Since 
se  is  equivalent  to 
negation  of  the 
unnecessary.  Eloom 
mming  -  initial 
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6  inefficiency  are 
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ECCHMANN73a 

Eochmann,  G.V. ;  Multiple  Exits  from  a  Loop  without  a 
16,7  (July  1973)  pp. 443-444. 


CE26,098 
Goto;  CACM 


The  author  proposes  anoth 
body  of  a  loop  distin 
termination  of  the  loo 
structure  extendable  to  t 


er  control  construct  which  outside  of  the 
guishes  between  normal  and  abnormal 
p.  This  appears  to  be  a  useful  control 
he  searching  of  linked  lists. 
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ECCHM;^.NN73fc 

Ecchmann,  G.V.;  Hierarchical  Language  Definition;  SIGPLAN  Notices 
8,9  (September  1973)  pp. 50-51. 

The  author  describes  a  basic  methodology  for  impleme  ntir.  g 
operating  systems  and  other  related  programs.  Starting  from  a 
basic  language  (machine  independent  but  implemented  on  each 
different  machine) ,  a  hierarchy  of  languages  is  described  each  of 
which  is  written  in  the  previous  language.  Only  when  implementing 
primitives  for  parallel  processes  does  the  real  machine  surface 
again  presumably  fcr  interrupts,  timing,  etc. 


ECEHM73 

Boehm,  E.W.;  Software  and  its  Impact:  A  Quantitative  Assessment; 
Datamation  19,5  (May  1973)  pp. 48-59, 


ECEHM75 

Ecehm,  B.W.,  McClean,  F.K.,  Urfrig,  D.B.;  Some  Experience  with 
Automated  Aids  to  the  Design  of  Large-Scale  Reliable  Software; 
IEEE  Transactions  on  Software  Engineering  SE-1,1  (March  1975) 
pp. 125-133. 

The  authors  give  a  motivation  for  the  construction  of  automated 
aids  to  be  used  in  the  design  of  large  software  systems:  according 
to  their  experience,  errors  in  large  systems  are  largely  caused  by 
incorrect  design.  Without  automated  aids  these  errors  are 
discovered  late  and  recovery  is  difficult.  For  errors  in 
consistency  of  data  (in  type,  format,  etc.)  they  show  that 
software  tools  are  able  to  detect  many  problems.  DACC  (Design 
Assertion  Consistency  Checker)  is  presented  as  an  example.  This 
system  detects  unused  variables  and  mismatches  between  input  and 
output  assertions  about  the  same  variable  in  large  software 
systems.  This  system  was  used  by  the  authors  in  the  development 
of  a  software  package  and  detected  818  mismatches  between  input 
and  output  out  of  121,000  possible  mismatches  at  a  cost  in 
computer  time  of  only  $30.  The  cost  of  providing  the  necessary 
input  data  is  "several  hundred  dollars".  The  authors  suggest  the 
addition  of  features  to  their  system  in  order  to  use  these  data 
fcr  documentation. 


EEINCH  HANSEN72a 

Erinch  Hansen,  P. ;  Structured  Multiprogramming;  CACM  15,7  (1972) 

pp. 574-578. 

The  author  presents  an  extension  to  the  programming  language 
PASCAL  to  permit  and  control  multiprogramming  in  a  structured 
manner.  He  introduces  the  concurrent  statement  COBEGIN  S1,S2,S3, 
CCEND  and  discusses  mutually  exclusive  operations  SI,  S2...  He 
permits  process  communication  via  shared  variables  and  "critical 
regions,"  introducing  a  REGION  group  not  unlike  a  DO  group,  but 
depending  on  a  shared  variable.  He  continues  from  here  to  the 
concept  of  an  event  variable  which  can  be  used  in  an  AWAIT 
statement  within  a  critical  region,  or  by  a  CAUSE  statement  in  a 
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critical  region  based  on  the  same  shared  variable.  The  addition 
of  this  structure  to  these  concepts  greatly  clarifies  the  intent 
of  the  programmer  and  eases  proof  of  correctness. 


EEINCE  HANSEN72b 

Erinch  Hansen,  P. ;  A  Compariscn  of  Two  Synchronizing  Concepts; 
Acta  Informatica  1  (1972)  pp. 190-199. 

The  author  examines  the  relative  merits  of  two  synchronization 
methods,  namely,  semaphores,  and  conditional  critical  regions. 
The  application  of  the  two  methods  is  outlined  on  the  writer- 
reader  problem  and  proofs  of  these  applications  are  presented. 

The  conclusions  the  author  reaches  suggest  that  the  ease  of 
applicability  of  either  method  depends  to  a  large  degree  on  the 
application.  Also  the  suggestion  is  made  that  the  conditional 
critical  region  concept  be  incorporated  as  a  primitive  into 
languages  that  are  designed  for  applications  involving  parallel 
processes. 


EEINCH  HANSEN73a 

Erinch  Hansen,  P.;  Testing  a  Multiprogramming  System;  Software 
Practice  and  Experience  3,2  (April-June  1973)  pp.  145-150. 

A  brief  description  of  the  testing  of  the  operating  system 
described  in  [Erinch  Hansen  70].  The  difficulties  of  testing  such 
a  system  are  noted.  The  testing  mechanism,  consisting  of  two  very 
short  additions  to  the  system  kernel  code,  was  designed  before  the 
code  for  the  system  was  written.  Since  the  system  was  designed  in 
a  series  of  nested  "programming  layers,"  each  layer  is  tested  and 
debugged  by  initializing  the  system  with  a  set  of  test  processes 
which  provide  tests  of  all  of  the  functions  of  the  particular 
layer.  The  need  for  a  "systematic  set  of  reproducible  test  cases" 
as  part  of  the  documentation  of  any  large  program  is  noted. 


EEINCH  HANSEN73b  CR26,104 
Erinch  Hansen,  P. ;  Operating  Systems  Principles ;  Prentice- Hall , 
Inc.,  Englewood  Cliffs,  N.J.  (1973)  pp. 1-366. 

This  book  is  an  excellent  overview  of  the  problems  and  trade-offs 
inherent  in  operating  system  design;  it  also  details  the  current 
state  of  their  solution.  Chapters  two  and  three  present  an 
abstract  view  of  computation  processes,  both  sequential  and 
asynchronous.  Chapters  four  through  six  discuss  techniques  of 
i  nple  irent  ing  processes  on  present-day  computers.  Chapter  seven 
outlines  the  emerging  field  of  protection,  and  chapter  eight 
describes  and  gives  a  critical  analysis  of  the  operating  system 
for  the  EC4000.  This  book  is  required  reading  for  anyone  who 
would  design  a  large  system,  or  would  like  to  know  how  such  a 
system  should  be  put  together. 
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EBC0KS75 

E rooks,  F.P.,  Jr.;  The  Mythical  Man-Month :  Hssa^s  on  Software 

Addison- Wesley  Publishing  Company  (1975)  pp.  1-195 


In  this  collection  of  15  essays,  the  original  manager  of  both 
System/360  (hardware)  and  OS/360  discusses  his  experiences  and 
insights  into  the  management  of  large  software  projects.  His 
thesis  is  that  large  software  projects  suffer  from  problems 
qualitatively  different  from  small  projects,  due  to  the  division 
of  labor  and  its  consequence:  dramatic  increases  in  communication 
requirements.  Some  of  the  schedule-destroying  aspects  of  large 
projects  are  covered,  including  design  inconsistencies  due  to 
size,  poor  time  estimates,  the  myth  that  the  man-month  is  an 
accurate  measure  of  programming  productivity,  and  others.  He 
concludes  that  the  most  important  goal  in  a  large  software  project 
is  maintaining  the  "conceptual  integrity"  of  the  system. 

The  book  is  fascinating,  not  only  because  of  the  unique  position 
of  its  author,  but  also  because  Brooks  has  managed  to  convey  what 
he  has  learned  in  an  entertaining  and  informative  manner. 


EECWN71a 

Brown,  F.D.,  Calderbank,  V.J.,  and 
the  Portability  of  a  Large  ALGOL 
SIE  on  KDF9;  Software  -  Practice 
December  1971)  pp. 367-371. 


CP23,00a 

Poole,  M.D.;  Some  Comments  on 
Program  -  The  Implementation  of 
and  Experience  1,4  (Octcber- 


In  this  paper  the  authors  described  their  task  of  movin 
program,  SID,  written  in  ALGOL,  to  a  new  machine,  KDF9. 
this,  four  major  difficulties  were  considered:  (1)  Is 
performed  by  the  program  independent  of  the  environment? 
the  language  of  the  program  a  subset  of  the  dialects  ac 
both  ALGOL  compilers,  and  do  these  compilers  interpret  th 
identically?  (3)  Does  the  program  satisfy  all  the  qua 
constraints  imposed  by  the  target  compiler?  (4)  is  a  conv 
hardware  representation  necessary,  if  so,  is  it  a 
operation? 
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EFCWN71 t 

Ercwn,  P.J.;  The  ML/I  Macro  Prcc 
Guide;  Computing  Laboratory,  Uni 
(October  1971)  pp.1-16. 

ML/I  is  a  general  purpose  macro  pr 
much  of  ML/I  and  shows  examples  o 
macro-processors  can  be  used  to  ex 
FORTRAN  with  a  while  statement)  to 
on  text,  or  to  allow  shorthand 
valuable  as  an  introduction  to  gene 


essor:  A.  Simple  Introductory 

versity  of  Kent  at  Canterbury 


ccessor.  This  manual  describes 
f  its  use.  General  purpose 
tend  languages  (e.g.  extending 
perform  simple  transformations 
for  text  entry.  This  paper  is 
ral  purpose  macro-processors. 


ERCWN72 

Brown,  G.  deW.;  The  Forum: 
Datamation  18,3  (March  1972) 


Programming , 
pp. 147-150. 


the  Quiet  Revolution; 
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In  the  sixties  programmers  were  considered  by  the  public  and 
themselves  as  heroes,  capable  of  solving  any  problem.  In  order  to 
face  new,  complex  problems  successfully,  programmers  must  adopt  a 
more  disciplined  attitude,  and  be  more  concerned  with  guality. 


EBCWN73  CR26,746 
Erown,  A.E.,  Sampson,  W.A.;  Program  Debugging;  American  Elsevier, 
New  York  (1973)  pp. 1-166. 


A  short, 
technique 
though  an 
It  gives 
provides 
[ ECOLE73 ] 


easily  read  text  which  discusses  some  of  the  problems  and 
s  for  debugging  large  programs.  It  is  a  bit  vague  -  even 
example  is  given  of  a  proposed  method  of  bug  correction, 
a  quick  overview  for  someone  new  to  the  field,  but 
little  that  is  original.  The  article  by  P.C.  Poole 
is  better. 


EBCWN74  CR28,099 
Brown,  P.J.;  Programming  and  Documenting  Software  Projects; 
Computing  Surveys  6,4  (December  1974)  pp, 213-220. 

The  paper  briefly  discusses  the  four  steps  in  the  execution  of 
software  projects:  planning,  coding,  testing,  and  final  usage.  It 
is  suggested  that  use  of  high  level  language,  good  error 
diagnostics,  good  documentation,  flexible  design,  etc.  will  help 
in  producing  good  software.  The  author  attempts  to  describe 
precautionary  measures  for  writing  good  programs. 


EURSTALL72 

Eurstall,  E.M.;  Some 
Programs  which  Alter 
(1972)  pp. 23-50. 


CR25,707 

Techniques  for  Proving  Correctness  of 
Data  Structures;  Machine  Intel lige nee  7 


This  paper  extends  the  work 
providing  techniques  for  proving 
that  deal  with  data  structure 
trees.  The  paper  reviews  Floyd's 
in  correctness  proofs.  Then,  a 
which  deal  with  handling  the  data 
several  examples  of  program  proof 


of  Floyd  [FL0YD67a]  and  others  in 
program  correctness  in  programs 
s  like  arrays,  lists,  and  binary 
technique  of  using  flow  diagrams 
fter  describing  some  new  concepts 
structures,  Eurstall  provides 
s  using  Floyd's  method. 


EUSHNELL71 

Bushnell,  R.C.;  User  Modifiable  Software;  Mathematical  Software , 
Academic  Press,  New  York  (1971)  pp. 59-66. 

This  paper  presents  arguments  for  easy-tc-modif y  software  in  a 
short,  well-written  paper.  Although  written  with  regard  to 
mathematical  systems,  the  suggestions  given  on  how  to  write 
modifiable  software  can  have  wider  applicability. 


EUXT0N71 

Buxton,  J.N.;  The  Nature  and  Implications  of  Software  Engineering; 
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in  Hugo,  J.S.  (ed) ,  The  Fourth  Generation,  Infotech,  Ltd., 
Berkshire,  England  (1971)  pp. 227-238. 

In  this  paper,  Buxton  attempts  to  make  clear  what  software 
engineering  is,  by  first  trying  tc  define  computer  science,  and 
then  by  explaining  how  software  engineering  differs  from  it. 
Secondly,  he  discusses  the  essential  nature  of  software 
engineering . 


CFEATHAM72a 
Cheatham,  T.E. 
Proceedings  of 


The  Recent  Evolution  of  Programming 
IFIP  Congress  71  (1972)  pp. 298-313. 


CR25,353 
L  angu  ages ; 


CHEATHAM72t 
Cheatham,  T 
Automating 
21 . 


CF,2  3,73U 

E.,  and  Wegbreit,  B. ;  A  Laboratory  for  the  Study  of 
Programming;  Proceedings  of  the  SJCC  40  (1972)  pp.ll- 
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programming  system  ECL  and  extensible  language  ELI  are 
ssed  as  the  basis  for  the  laboratory;  initial  operation  of 
lab  and  approaches  used  are  briefly  described.  Components  of 
at  include  a  control  path  (in  a  multiprogramming  environment, 
is  the  interface  with  the  user) ,  a  programmaole  theorem 
r,  a  data  base  of  theorems  for  program  transformations,  a 
rn  matcher,  backtracking  mechanism,  and  program  performance 
rement  techniques. 
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CIi^RK73 

Clark,  B.L.  and  Horning,  J.J.;  Reflections  on  a  Language  Designed 
to  Write  an  Operating  System;  SIGPLAN  Notices  8,8  (September  1973) 
pp. 52-56. 

The  authors  express  their  cpinicns  on  the  crucial  issues  in  the 
design  of  a  high-level  system  language,  based  on  experience  with 
Project  SUE.  Various  advantages  of  languages  emphasizing 
structure  (program  and  data) ,  redundancy,  and  efficiency,  over 
traditionally  used  machine  dependent  language  are  outlined.  An 
example  program  is  included  at  the  end  to  illustrate  the  above 
points . 

CLINT72 

Clint,  M.,  and  Hoare,  C.A.R.;  Program  Proving:  Jumps  and 
Functions;  Acta  Informatioa  1,3  (1972)  pp. 214-224. 

The  authors  argue  for  the  validity  of  using  the  'goto'  construct 
in  two  speoial  cases,  namely,  as  a  means  of  exiting  a  very  deep 
loop  nest  and  as  a  failure  exit.  Their  arguments  are  supported  by 
a  proof  method  for  this  restricted  class. 

A  discussion  of  functions  and  function  calls  examines  the  special 
problems  that  these  constructs  present  to  program  proofs,  and 
leads  to  a  method  to  handle  these  cases. 

The  paper  concludes  with  an  example  illustrating  the  methods 
outlined. 


CLINT73  CP27,211 
Clint,  M. ;  Program  Proving:  Coroutines;  Acta  Informatica  2  (1973) 
pp . 50-63 . 


This  paper  discusses  an  extension  to  the  proof 
given  by  Hoare,  so  that  Simula-like  coroutines 
The  new  proof  rule  is  stated  and  its  use 
example.  The  paper  is  not  of  much  interest  to  th 
for  it  adds  no  new  concepts  to  previous  work, 
not  to  say  the  paper  is  without  content  and  it  is 
kr.ow  that  the  methodology  can  be  extended  to  furt 


rules  and  axioms 
can  be  handled, 
illustrated  by  an 
e  general  reader. 
However,  this  is 
interesting  to 
her  constructs. 


CCEEN72 

Cohen,  A.;  Modular  Programs:  Defining  the  Module;  Datamation  18,1 
(January  1972)  pp. 34-37. 

Modular  programming  is  a  useful  tool  if  applied  skillfully.  The 
author  gives  a  feeling  for  the  right  decomposition  of  your  problem 
into  modules  by  considering  typical  file  processing  programs. 


CCEEN74 

Cohen,  J. ,  and  Zuckerman,  C. ;  Two  Languages  For  Estimating  Program 
Efficiency;  CACM  17,6  (June  1974)  pp. 301-308. 
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CCLE73 

Ccle,  N.M.,  and  Seikel,  M.J.;  Solving  a  Software  Design  Problem 
Using  Plain  English;  Datamation  19,10  (October  1973)  pp. 101-106. 


This  article  describes  a 
English  is  not  really 
language.  The  macros 
familiar  with  the  system, 
macros  is  such  that  low 
knowledge  of  the  system, 
without  too  much  diffic 
increased  efficiency,  a 
resources . 


method  cf  top-down  prog 
used,  but  rather  a 
are  written  by  tcp- 
and  the  information 
-level  programmers,  who 
can  flowchart  and 
ulty.  The  authors  clai 
nd  more  effective  us 


ram  design.  Plain 
high-level  macro 
level  programmers 
content  of  the 
lack  the  detailed 
code  the  program 
m  savings  in  time, 
e  of  programmer 


CCCKE75 

Ccoke,  J.E.,  and  Eunt,  R.E.;  Human  Error  in  Programming:  The  Need 
to  Study  the  Individual;  INFOB  13,3  (October  1975)  pp. 296-307. 


The  authors  list  three 
the  interactions  within  a 
the  individual  programmer 
a  human  inf ormaticn-proce 
dealing  with  the  curre 
authors  state  that  there 
the  informaticn  process 
particular,  eye  movement, 
problems  cf  methodology 
approach  is  suggested. 


levels  of  human  effects  on  programming  -- 
programming  group,  the  personality  of 
,  and  the  capability  cf  the  programmer  as 
ssing  system.  After  reviewing  literature 
nt  programming  technigues  and  styles,  the 
exists  a  need  for  experimental  studies  of 
ing  limitations  cf  the  programmer  --  in 
perception,  and  short-term  memory.  Some 
are  considered,  and  an  experimental 


CCBEATC72 

Ccrbato,  F.J.,  Saltzer,  J.H.,  and  Clingen, 
First  Seven  Years;  Proceedings  of  the  SJCC 


CE25,199 
C.T.;  MULTICS  -  The 
40  (1972)  pp. 571-583. 


Althouqh  intended  as  a  review  and  current  status  report,  this 
paper  provides  an  interesting  descript_cn  cf  the  progress  of  the 
design  and  i mplementaticn  of  a  very  large,  very  complex  research 
project  with  real  life  goals.  In  their  ccnclusicns,  the  authors 
make  the  point  that  computer  utility  systems  must  evolve,  since 
the  costs  of  redesign  and  re- implementation  are  too  high  to  allow 
any  ether  procedure.  This  is  almost  certainly  true  of  any  very 
large,  complex  system  which  is  to  serve  a  community  of  users  who 
(1)  will  net  wait  for  the  ultimate  to  arrive  at  the  expense  of  not 
doing  anything  until  it  does;  (2)  are  used  to  a  particular 
environment,  and  see  no  real  need  to  unlearn  everything. 


CCEBIN71 

Corbin,  K.,  Corwin,  W.,  Goodman,  P.  ,  Hyde,  E.,  Kramer,  K. ,  Werme, 
E.,  Wulf,  W. ;  A  Software  Laboratory  Preliminary  Report;  Carnegie- 
Mellon  University  Computer  Science  Dept.  Technical  Report  (August 
1  971)  . 

This  paper  describes  a  system  which  allows  students  and 
researchers  to  construct  software  systems.  Systems  are  to  be 
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built  by  "plugging  together"  modules  in  a  data-flow  manner.  This 
system  would  have  characteristics  like  the  Data-flow  Programming 
Language  described  in  [ KOSINSKI73 ],  the  "macro  modules"  of 
[CLARK73],  and  messages  between  processes,  as  in  the  system.  An 
i nplementation  strategy  and  a  kernel  are  presented  which  support 
this  system. 


CCSGECVE71 

Ccsgrove,  J.;  Needed  Now:  New  Planning  Framework;  Datamation  17, 
23  (December  1971)  pp. 37-39. 

The  author  describes  the  problems  of  programming  management.  He 
discusses  what  is  wrong  with  the  traditional  way  of  handling 
programmers,  and  how  they  should  be  dealt  with  in  this  time  of 
increasingly  more  complex  problems. 


CCX71 

Cox,  P.R.;  Machine  -  Independent  Operating  Systems:  A  Functional 
Approach  To  Design;  in  Hugo,  J.S.(ed.),  The  Fourth  Generation, 
Infotech,  ltd.  (1971)  pp. 239-258. 

The  term  operating  system,  as  currently  used  in  the  computer 
industry,  is  virtually  undefinable.  There  is  a  large  set  of 
functions  that  nearly  all  operating  systems  do  perform,  but  this 
set  is  inclined  to  become  a  little  fuzzy  around  the  edges. 


In  this  paper,  Cox  attempts  to  set  forth 

required  in  a  machine  -  independent  operating 
software  at  the  higher  level.  He  feels 
required  as  to  the  function  of  operating 

philosophy  behind  them,  rather  than  on  what 
or  a  particular  operating  system  does. 


objectives  that  are 
system  and  portable 
that  more  thought  is 
systems  and  the 
a  particular  machine 


CDMMING71 

Cumming,  C.B.;  Monitoring  the  Operation 
Software  -  Practice  and  Experience  1,4  (1971 


of  System 
pp. 383-389 


CR23,205 
Soft  ware ; 


EAHL72 

Dahl,  O.J.,  and  Hoare,  C.A.R.;  Hi 
Dahl,  O.J.,  Dijkstra,  E.W., 
Picsramming,  Academic  Press,  New 

This  paper  describes  an  elega 
control  concepts  in  the  "class 
language.  Examples  are  given  t 
represent  a  general  data  structur 
specific  instances  of  the 
Demonstration  is  also  given  of  th 
the  implementation  of  coroutin 
weakened  by  the  stress  placed  on 
simulation  studies,  and  by  the 
felt  it  necessary  to  make  variabl 


erarchical  Program  Structures;  in 
and  Hoare,  C.A.R.,  Structured 
York  (1972)  pp. 175-220. 

nt  merging  of  structured  data  and 
"  construct  of  the  SIMULA  67 
o  show  how  a  class  may  be  used  to 
e  and  operaticES  on  it  and  how 
struoture  may  be  generated, 
e  use  of  the  class  concept  for 
es .  The  exposition  is  somewhat 
the  use  of  the  language  for 
fact  that  the  language  designers 
es  of  a  class  object  accessible 
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from  outside  the  object.  Nonetheless,  the  concepts 
certainly  worthy  of  further  attention,  particularly 
toward  restoring  locality  of  data  to  the  class. 


presented  are 
with  a  view 


D;^KIN73 

Dakin,  R.J.,  and  Foole,  P.C.;  A  Mixed  Mode  Approach;  The  Computer 
Journal  16,3  (August  1973)  pp. 219-222. 

This  paper  uses  the  development  of  a  version  of  the  MITEM  text 
editor  to  describe  the  notion  of  mixed  coding.  This  consists  of 
using  interpretive  and  direct  cede  in  the  same  system.  Also 
discussed  are  the  adaptability  of  code  generation,  selective 
optimization  of  run  time  and  program  space  in  code  generation. 


The  system  was  first  run  interpre tively  and  moni 
that  97%  of  the  execution  time  was  spent  in  less 
of  the  source  code.  These  frequently  exec 
changed  to  direct  code,  and  the  rest  of  th 
interpretive.  This  mixture  combines  the  speed 
the  efficient  space  utilization  of  interpretive 
overhead  of  mixed  code  was  found  to  be  very 
three  to  five  times  faster  than  the  interpretive 
only  10-20%  slower  than  the  direct. 
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the  authors  give  some  ideas  on  how  a  mixed 
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DENIL73 

Denil,  N.J.;  Software  Design  with  Invocation  Diagrams; 
Notices  8,9  (September  1973)  pp. 57-59. 

The  author  describes  a  medium  for  expressing  abstra 
programs  (especially  their  structure) .  He  claims  program 
designed  top  down  with  this  medium;  only  the  "logic  of  th 
is  crucial.  The  medium  provides  for  diagrams  of 
structure  of  the  programs  as  observed  from  the  program 
the  data  communicated  between  modules,  and  the  effects  ea 
has  on  the  communicated  data. 


SIGPLAN 


ctions  of 
s  can  be 
€  design" 
data  and 
mod  ules , 
ch  module 


DENNIS75 

Dennis,  J.E.;  First  Version  of  a  Data  Flow  Procedure  Language; 
MIT,  Project  MAC  Technical  Memorandum  61  (May  1975)  pp.1-21. 

In  this  paper  Dennis  describes  a  language  for  representing 

computational  procedures  based  on  the  concept  of  data  flow.  The 

language  is  presented  in  terms  of  a  semantic  model  that  permits 

concurrent  execution  of  noninterfering  program  parts.  The 
language  is  able  to  effectively  represent  block  structured 

programs.  It  is  also  consistent  with  the  concept  of  modular 
programming,  but  has  not  yet  been  extended  to  provide  appropriate 
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means  for  supporting  the  notion  of  function  clusters  as  proposed 
by  Liskov  and  Zilles. 

The  paper  gives  an  excellent  introduction  to  the  concept  of  data 
flew  languages,  which  are  being  researched  by  the  Computation 
Structure  Group  at  project  MAC,  in  an  effort  to  study  the  design 
of  a  "common  base  language".  (The  base  language  contributes 
significantly  to  the  ability  of  computer  users  to  easily  construct 
correct  programs.)  The  data  flow  language  is  being  used  as  a  model 
for  study  of  fundamental  semantic  constructs  for  programming,  as  a 
target  language  for  evaluating  translatability  of  programs 
expressed  at  the  user-language  level,  and  as  a  guide  for  research 
in  advanced  computer  architecture. 


DEFEMER75 

DeRemer,  F.L.,  and  Kron,  H. ;  Programming-in-the-small  versus 
Programming-in-the-large;  International  Conference  on  Reliable 
Software,  SIGPLAN  Notices  10,6  (June  1975) 

The  authors  of  this  paper  distinguish  two  types  of  programs: 
"small"  programs  of  less  than  a  few  pages  in  length  and  easily 
comprehended  by  a  single  programmer,  and  "large"  programs,  which 
include  all  others  but  usually  mean  systems  containing  other 
modules,  perhaps  written  by  several  different  programmers.  They 
argue  that  today’s  languages  are  adequate  only  for  programming-in- 
the-small,  and  that  a  new  language  is  needed  to  specify  how 
smaller  modules  are  linked  together  to  form  a  system. 

A  prototype  language  called  MIL/1  is  described.  Advantages 
include  a  compiler  checkable  specification  of  a  greater  amount  of 
the  intent  of  the  programmer;  tools  for  project  management  and 
documentation;  and  a  means  of  communication  between  members  of  a 
programming  team,  especially  a  chief  programming  team. 

DEUTSCH72 

Deutsch,  P.,  and  Grant,  C.A.;  A  Flexible  Measurement  Tool  for 
Software  Systems;  Proceedings  of  IFIP  Congress  71  (1972)  pp.320- 
3  26. 


DIJKSTRA71a 

Dijkstra,  F.W.;  Concern  For  Correctness  as  a  Guiding  Principle  for 
Program  Composition;  in  Hugo,  J.S.  (ed) ,  The  Fourth  Generation , 
Infotech  Ltd.,  Berkshire,  England  (1971)  pp. 357-367. 

In  this  state-of-the-art  report,  Dijkstra  reviews  the  current 
state  in  the  programming  world,  and  notes  the  unfortunate 
situation  with  respect  to  programming  and  debugging  practices.  As 
an  alternative  to  this,  he  proposes  and  presents  a  strong  argument 
for  a  structural  approach  to  the  construction  of  "intellectually 
manageable"  programs  which  yields  correctness  proofs  with  much 
less  effort. 
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DIJKSTE;^.71b 

Dijkstra,  Z.W.;  A  Short  Introduction  to  the 
Eindhoven  University,  Ewr316  (August  1971) 


DIJKSIEA72a 

Dijkstra,  E.W.;  The  Humble  Programmer;  CACM 
pp . 859-866 ; 

The  author  reflects  on  the  historical  development  of  programming. 
Initial  hardware  constraints  and  the  nature  of  the  slowly 
developing  field  resulted  in  puzzle-minded  program ners  who 
optimized  the  computing  process.  The  introduction  of  second  and 
third  generation  computers  only  heightened  the  problems. 

In  looking  to  the  future  he  foresees  that  projects  that  are  of 
limited  size  will  be  done  with  much  less  effort  and  many  fewer 
bugs.  This  will  be  accomplished  by  limiting  ourselves  to 
"intellectually  manageable  programs."  A  number  of  reasons  for  this 
are  given,  as  well  as  some  impediments.  To  be  humble  programmers, 
it  is  necessary  to  realize  the  magnitude  of  the  problems,  the 
usefulness  of  the  tools,  and  the  limitations  of  the  human  mind. 


Art  of  Programming; 
pp . 1- 97 . 


CR24,552 
15,  10  (October  1972) 


DIJKSTEA72h 

Dijkstra,  E.W.,  Notes  on 
Dijkstra,  E.K.,  and 
Academic  Press,  New  York 


Structured  Programming,  in 
Hoare,  C.A.E.,  Structured 
(1972)  pp.1-82. 


CF26,36a 
Dahl,  O.d., 


This  first  section  of  th 
on  Structured  Programmin 
wrote  to  himself  while 
The  notes  are  informal  i 
topic,  but  display  con 
any  one  idea.  The  init 
program  being  correct 
on  top-down  programming 
designed  to  convince 
taught  successfully. 


e  book  is  by  Dijkstra,  and  entitled  " 
g."  It  is  an  informal  set  of  note 
contemplating  the  problems  of  program 
n  that  they  tend  to  meander  through 
siderable  formality  in  the  presentati 
ial  comments  on  the  probability 
are  based  on  shaky  premises.  The  sec 
are  worthwhile.  The  last  section 
the  reader  that  programming  style  c 
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DIJKSTEA73 

Dijkstra,  E.W.;  A  Simple  Axiomatic  Basis  For  Programming  Language 
Constructs;  EWD372,  Technological  University,  Eindhoven  (1973). 

An  axiomatic  basis  for  programming  language  constructs  and  their 
impact  on  efforts  to  prove  programs  correct  is  discussed. 
Starting  with  the  desired  result  expressed  as  a  postcondition 
predicate  P,  he  derives  the  weakest  precondition  for  a  construct 
such  that  after  execution  of  the  construct,  P  is  satisfied.  The 
axioms  for  the  derivations  are  described  for  many  (including  the 
mcst  useful)  constructs,  including  recursion.  The  main  advantage 
of  this  approach  is  that  it  appears  mathematically  simpler  than 
similar  approaches  to  this  problem. 
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DCNAH0E75 

Donahue,  J.E.;  Mathematical  Semantics  as  a  Complementary 
Definition  for  Axiomatically  Defined  Programming  Language 
Constructs;  in  Three  Approaches  to  Reliable  Software:  Language 
Design,  Dyadic  Specification,  and  Complementary  Semantics; 
Technical  Report  44,  Computer  Systems  Research  Group,  University 
of  Toronto  (January  1975). 


Hoare's  axiomatic  definitions  of  programming  language  sema 
have  been  the  most  fruitful  approach  to  proving  pr 
correctness.  In  certain  other  respects,  however,  the  axio 
approach  has  proven  deficient:  it  may  conceal  certain  sem 
aspects,  and  it  does  net  provide  a  useful  implementation  m 
The  author  argues  that  the  "mathematical  semantics"  of  Scott 
Strachey  provides  a  useful  complementary  definition  techniq 
the  axiomatic  approach.  The  question  of  demonstrating 
consistency  of  mathematical  and  axiomatic  definition 
addressed . 
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ELSPAS71 

Elspas,  E.,  Green,  M.W.,  and  Levitt,  K.N. ;  Software  Reliability; 
Computer  4,1  (January/February  1971)  pp. 21-27. 

In  this  article  we  have  an  overview  of  the  general  streams  of 
software  reliability.  The  first  area  discussed  is  that  of  language 
design  where  the  authors  present  a  case  for  a  wide  range  of 
program  checlcing  devices  which  would  enforce  discipline  on  a 
program.  The  second  area  considered  is  that  of  semantic  checking, 
where  a  case  is  presented  for  checking  the  semantics  of  code  via 
automatic  path  testing.  Lastly,  the  authors  take  a  brief  look  at 
automatic  program  verification.  Seme  informal  proof  techniques  are 
examined  in  some  detail  with  a  proof  for  a  small  piece  of  code 
being  provided.  A  brief  summary  is  given  of  the  more  formal  proof 
techniques . 


EISPAS72 

Elspas,  E.,  Levitt,  K.N.,  Waldinger,  R.J. 
Assessment  of  Techniques  for  Proving 
Computing  Surveys  4,2  (June  1972)  pp. 97-147 


CR25,396 
and  Wakeman,  A. ;  An 
Program  Correctness; 


An  excellent  survey  of  proof  techniques  of  interest  to  both  the 
person  unexposed  to  program  verification  techniques  and  as  an 
overview  for  the  person  actively  interested  in  this  area.  The 
article  reviews  both  formal  and  informal  approaches  to  program 
verification  in  some  detail,  including  work  by  Floyd,  Hoare, 
Manna,  London  and  many  others. 


ERSHOV72 

Ershov,  A.P.;  Aesthetics  and  the 
15,  7  (July  1972)  pp. 501-505. 


CR24,022 

Human  Factor  in  Programming;  CACM 


-2  8- 


Current  ^.rticles 


FIENT73 

Fient,  H.G.;  Management  of  the  Acquisition  Process  fcr  Software 
Products;  Management  Informatics  2,3  (June  1973)  pp. 153-164, 


A  discussion  of  softwar 
increasing  cost  of  softwa 
buy,  rather  than  develop, 
dissatisfaction  resulting 
article  gives  the  pres  a 
an  overview  of  the  softw 
supply  and  information 
complaints.  A  detailed  b 
encountered  is  given 
maintenance,  testing,  dec 
description  of  software 
user  and  supplier  is  give 


€  brokerage  as  a  possible  solution  to  the 
re  development  and  the  rising  tendency  to 
application  software  with  the  consequent 
from  lack  of  standards  and  control.  The 
nd  cons  of  writing  one’s  own  software  and 
are  product  market  giving  sources  of 
and  listing  typical  user  and  supplier 
reakdown  of  the  requirements  typically 
covering  costs,  design,  ease  of  use, 
umentation  and  contracting.  Finally  a 
brokerage  detailing  services  provided  to 
n. 


FISHEE72 

Fisher,  D.A.;  A  Survey  of  Control  Structures  in  Programming 
Languages;  SIGPLAN  Notices  7,11  (November  1972)  pp.1-14. 


This  paper  examines  the  control  structures  of  progra 
languages  and  how  the  constructs  are  developed.  Progress  has 
made  by  specialization  through  composition  of  a  few  very  ge 
primitive  operations.  The  dominance  of  the  underlying  segue 
machine  is  apparent  throughout  this  process.  In  some  areas 
specialization  has  lead  to  clarity  and  efficiency,  while  in  o 
the  accompanying  loss  of  generality  has  had  the  opposite  effe 
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F1CYD72 

Floyd,  E.W.;  Toward  Interactive  Design  of  Correct 
Proceedings  of  IFIP  Congress  71  (1972)  pp.7-10. 


CE25,232 
Prog  rams ; 


An  imagined  interaction  between  a  computer  progra 
machine  is  described,  in  which  the  computer  checks  the 
consistency  with  the  programmer's  stated  intentions 
the  logical  or  semantic  correctness  of  the  program 
levels. 
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FCNG73 

Fong,  F.N.;  Improving  Compiler  Diagnostics;  Datamation  19,  4 

(April  1973)  pp, 84-86. 

Most  of  a  programmer's  effort  in  program  development  is  spent  in 
debugging.  The  author  suggests  seme  debugging  and  monitoring 
facilities.  These  are  divided  into  three  different  groups. 
Cempile-time  checks  include  syntax  checking,  cross  reference 
listing,  modularity,  paragraphing,  and  static  control  concordance. 
Formal  and  actual  argument  checks  and  static  subroutine  analysis 
can  be  performed  at  link/load  time.  Execution-time  checks  include 
dynamic  traces  of  subroutine  calls,  flow  of  control,  and  variables 
in  addition  to  snapshot  dumps  and  address  checking. 
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FCSDICK72 

Fcsdick,  L.D. ;  The  Production  of  Eetter  Mathematical  Software; 
CJ^CM  15,7  (July  1972)  pp. 611-617. 

In  this  article  a  number  of  suggestions  are  made  for  future  work 
in  the  area  of  software  production.  Although  it  is  ostensibly 
oriented  towards  the  problem  of  the  production  of  mathematical 
software,  it  is  not  particularly  dependent  on  any  peculiarities  of 
this  class  of  software.  The  suggestions  are  divided  into  the  areas 
of  design,  validation,  docume ntatior.  and  standards.  It  points  out 
the  strong  coupling  between  these  areas.  It  completely  ignores  the 
guestions  of  the  organization  and  mechanics  of  the  production  of 
software,  such  as  is  treated  in  Mills  and  Baker, 


The  article  is  uneven  and  perhaps  too  shallow  in  its  treatment  of 
the  problems  in  the  areas  discussed,  but  it  is  provocative.  It 
suggests  in  simple  terms  the  areas  that  every  programmer  must 
consider  if  he  is  to  be  able  to  be  at  all  successful  in  producing 
worthwhile  programs.  It  provides  a  first  crack  at  a  reading  list 
for  programmers  in  support  of  their  professional  responsibilities. 
One  very  interesting  idea  emerges  from  the  article  and  that  is  the 
idea  cf  truly  automatic  program  documentation,  the  latter  to  be 
interpreted  in  a  broad  sense. 
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n  and  Horning  investigate  the  effects  of  langua 
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GHAN71 

Ghan,  I. ;  Eetter  Technigu 
Programs;  Proceedings  o 
pp. 520-537. 


CE2 

es  for  Developing  Large  Scale  FO 
f  the  26th  ACM  National  Conference  ( 


2,433 

BTRAN 

1971) 


Cost  reductions,  particularly  in  the  development  of  large  scale 


FCRTEAN  scientific  computer  programs,  are  desirable,  but 
easy  to  realize  because  of  enduring  development 
associated  with  large  programs.  This  paper  examines 
significant  of  these  problems  and  suggests  ways  to  treat 
problems  addressed  here  were  identified  over  a  period 
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spent  developing  a  family  of  large  FORTRJ^.N  simulation  pregrams  at 
Seeing.  The  techniques  discussed  were  evolved  during  the 
development  of  these  programs  and  are  of  proven  effectiveness. 
Particular  emphasis  is  placed  on  the  use  of  higher  level  software, 
interprogram  communication  techniques  and  good  basic  coding 
practices . 

GCOLD'71  CE22,292 
Gould,  J.S.;  On  Automatic  Testing  of  On  Line  Real  Time  Systems; 
Proceedings  of  the  SJCC  36  (1971)  pp. 477-484. 


GCULD73 

Gculd,  T.D.;  Some  Psychological  Evidence  on  How  People  Debug 
Computer  Programs;  RC  4542  (7E20208) ,  IBM  Thomas  J.  Watson 
Research  Center,  Yerktown  Heights,  Hew  York  (September  1973)  pp.1- 

P  "5 

This  paper  reports  the  results  of  a  study  on  how  experienced 
Fortran  programmers  from  the  IBM  Research  Center  debugged  Fortran 
programs  which  contained  single-line  errors.  Two  motivations  for 
the  experiment  were  to  analyze  and  report  on  various  debugging 
strategies,  and  to  compare  the  way  programmers  debugged  when 
allowed  to  use  interactive  debugging  tools.  Results  included 
observations  that 

1)  "Highly  motivated"  subjects  could  debug  the  programs  as 
efficiently  when  just  examined  the  listing  as  they  could  when  they 
had  access  to  what  had  been  considered  aids; 

2)  Subjects  found  meaningful  mnemonics  useful  in  debugging. 

3)  Bugs  in  assignment  statements  were  the  most  difficult  to 
debug,  primaril  because  subjects  had  to  have  a  more  thorough 
understanding  of  the  substance  of  the  program. 

Studies  of  this  nature  are  open  to  a  great  number  of  criticisms. 
One  criticism  concerns  the  conclusion  that  programmers  didn't  seem 
to  use  what  were  considered  debugging  aids;  the  reasons  for  not 
using  the  interactive  system  provided  were  too  numerous  (lack  of 
programmer  familiarity  and  poor  design  of  the  interactive  system, 
to  name  two)  to  support  such  conclusions  very  strongly.  On  the 
whole,  however,  the  paper  seems  useful  in  providing  a  documented 
study  of  the  programming  process,  and  shedding  some  light  on  the 
debugging  task. 

GRA.HAM71 

Graham,  R.M.,  Clancy,  G.J.,  and  DeVaney,  D.B.;  A.  Software  Design 
and  Evaluation  System;  Proceedings  of  the  ACM/SIGOPS  Workshop  on 
System  Performance  Evaluation  (April  1971)  pp. 200-213, 

There  are  two  primary  drawbacks  to  modelling  as  a  part  of  the 
implementation  process.  First  is  the  need  to  construct  the  model 
separately  from  the  system,  diverting  people  from  the  primary 
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objective.  Second  is  the  problem  of  keeping  the  model  current  as 
the  system  primitives  are  re-defined. 

DES  makes  use  of  a  single  language  to  describe  the  object  system 
at  all  levels  of  design  and  implementation.  In  this  way 
simulation  goes  hand-in-hand  with  design  and  the  performance  of 
the  final  system  may  be  accurately  estimated  before  full 
implementation,  potentially  saving  a  costly  re-design. 


GPi^H;^.M73a 

Graham,  R.M.,  Clancy  Jr.,  G.J., 
Design  and  Evaluation  System; 
116. 


CR25,424 

and  Devaney,  D.E.;  A  Software 
CJ-.CM  16,2  (February  1973)  pp.110- 


The  DES  system  is  an  operating  system  writing  system,  im 
in  a  superset  of  PL/1.  Procedures,  data  items  and 
characteristics  are  maintained  in  a  data  set  that 

simulating  the  performance  of  incompletely  written  su 
Each  component  can  be  evaluated  to  produce  a  graph  repre 
of  the  procedure,  information  on  external  references, 
usage  and  interface  and  constraint  violations.  The  me 
produces  a  probabilistically  collapsed  graph  of  the 
system  which  is  input  to  a  general  purpose  s 

Unfortunately,  asynchronous  behavior  is  not  adequately 
Essentially,  this  is  still  a  *toy*  system  since  its  auth 
that  no  large  system  like  the  Multics  system  could  be  sue 
modelled. 
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GEAHAM73b 

Graham,  S.L.,  and  Rhodes,  S.P.;  Practical  Syntactic  Error  Recovery 
in  Compilers;  ACM  Symposium  on  Principles  of  Programming 
Languages,  Boston,  Mass.  (October  1973)  pp. 52-58. 

The  article  proposes  a  method  of  error  detection  and  recovery  to 
"maximize  the  numbers  of  errors  detected"  and  "minimize  the  number 
of  times  it  reports  an  error  when  there  is  none."  The  aim  of  the 
system  is  thus  to  minimize  the  number  of  runs  needed  to  debug  a 
program  with  syntax  errors.  The  method  is  composed  of  two  parts:  a 
condensation  phase  where  the  system  tries  to  locally  recover  from 
the  error  and  continue  parsing,  and  a  correction  phase  which 
attempts  to  correct  the  error. 


GRIFFITH72 

Griffith,  P.F.,  and  Henry,  R.M.;  An  Investigatory  Study  into  Human 
Problem  Solving  Capabilities  as  They  Relate  to  Programmer 
Efficiency;  SIGCPR  Bulletin  3,3  (1972)  pp.  10-14. 

This  paper  is  detailed  description  of  a  research  study 
investigating  programer  efficiency  as  it  relates  to  maintaining 
varying  numbers  of  COBOL  data  processing  programs.  The  results 
showed  that  greater  programmer  efficiency  occurred  in  solving  3 
problems  in  parallel  than  solving  3  problems  sequentially.  The 
sample  size  was  18  subjects.  Hence  the  results  are  at  best 
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marginally  significant.  These  results  seem  contrary  to  other 
results  noted  in  'current  literature*,  but  did  generate  much 
enthusiasm  in  the  subjects  doing  the  parallel  processing. 


GEIES71 

Cries,  E.;  Compiler  Construction  for  Digital  Computers ;  Wiley, 
N.Y.  (1971)”pp. I-493T 


GBIES74 

Cries,  D. ;  On  Structured  Programming  -  A  Reply  to  Smcliar;  CACM 
17,11  (November  1974)  pp. 655-657. 

A  well  reasoned  well  stated  attempt  to  explain  the  connotations  of 
the  term  "structured  programming." 


GUNDEBMAN73 

Gunderman,  B.E.;  A  Glimpse  into  Program  Maintenance;  Datamation 
19,6  (June  1973)  pp. 99-101. 

Program  maintenance  is  described  as  "a  large  and  continually 
growing  area  of  activity  which  is  taking  its  toll  in  time,  money, 
manpower,  computer  use,  profits,  etc."  These  problems  are 
attributed  to  maintenance  having  been  largely  ignored,  or  viewed 
as  an  activity  for  second  class  programmers  who  are  not  yet 
capable  of  original  program  development.  The  lack  of  published 
literature  and  research  on  debugging  is  a  problem.  A  typical 
system  problem  and  the  implications  of  fixing  it  are  described  and 
the  organization  of  an  effective  "maintenance  facility"  is 
discussed . 


GUTTAG75 

Guttag,  J.V.;  Dyadic  Specification  and  its  Impact  on  Reliability; 
in  Three  Approaches  to  Reliable  Software:  Language  Design,  Dyadic 
Specification,  and  Complementary  Semantics;  Technical  Report  44, 
Computer  Systems  Research  Group,  University  of  Toronto  (January 
1  975)  . 

The  specification  of  data  types  is  normally  carried  out  in  either 
a  procedural  or  a  descriptive  manner.  Each  technique  has  its 
advantages  and  its  lim itations.  Guttag  presents  an  algebraic 
specification  technique  combining  the  best  features  of  the 
procedural  and  descriptive  approaches.  He  discusses  its 
implications  for  structured  design  and  specification,  correctness 
proofs,  and  program  testing.  His  eventual  goal  is  an  interactive 
specification  system  that  will  recognize  (and  help  construct)  a 
set  of  axioms  sufficient  to  fully  describe  a  data  type  in  an 
iff pie mentation -indepen dent  manner . 


H*EERM;'.NN73 

Habermann,  A.N.;  Integrated  Design;  SIGPLAN  Notices  8,9  (September 
1973)  pp. 64-66. 
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^iPi  argument  is  given  for  the  integration  of  the  design,  analysis, 
and  i nplementation  efforts  of  a  programming  system  into  one 
production  effort  in  which  documentation  is  a  primary  issue.  Also 
it  is  argued  that  the  design  concepts  should  net  be  presented  in 
the  language  chosen  for  implementation  as  it  may  dominate  the 
project. 


HALSTEAD72 

Halstead,  M.H.;  Natural  laws  Controlling  Algorithm  Structure?; 
SIGPLAN  Notices  7,2  (February  1972)  pp. 22-30. 

The  author  proposes  that  algorithms  obey  natural  laws,  which  are 
based  on  two  independent  properties,  the  number  of  distinct 
operators  and  the  number  of  distinct  operands.  A  certain  function 
of  these  properties,  called  the  Internal  Quality  of  an  algorithm, 
is  said  to  be  independent  of  the  language  in  which  the  given 
algorithm  is  expressed.  The  statistics  presented  are,  to  say  the 
least,  unconvincing. 


HALSTEA.D73 

Halstead,  M.H.;  Language  Selection  for  Applications;  Proceedings 
of  the  SJCC  42  (June  1973)  pp. 211-214. 

The  author  outlines,  guidelines  for  selecting  a  new  language  for  a 
given  application.  Four  important  considerations  which  should  be 
recognized  when  making  such  decisions  are:  1.  How  a  programmer 
spends  his  time  2.  Differences  in  Iccal  and  global  inefficiency  3. 
The  role  of  the  expansion  ratio  4.  Variance  in  programmer 
productivity. 

While  describing  these  considerations,  the  author  points  out  costs 
which  vary  over  the  language  used. 

Finally,  the  author  concludes  by  mentioning  those  critical  factors 
which  should  be  weighed  in  a  management  decision  for  an  alternate 
high  level  language.  These  involve:  whether  the  higher  level 
language  (higher  than  what  is  currently  in  use)  is  high  enough  for 
a  sufficiently  large  majority  of  program  applications,  that  data 
collected  on  small  programs  is  not  representative  of  the  crucial 
programs  (i.e.,  the  large  ones)  and  that  costs  of  conversion  from 
the  new  language  to  another  computer  are  a  very  important 
consideration. 


HANEY72 

Haney,  F.M.;  Module  Connection  Analysis  -  A 
Software  Debugging  Activities;  Proceedings 
pp. 173-179. 


CE25,504 
Tool  for  Scheduling 
of  the  FJCC  41  (1972) 


Presents  a  method  for  estimating  the  amount  of  work  necessary  to 
make  changes  to  a  large  system,  or  to  complete  the  final  testing 
and  integration  of  such  a  system.  For  a  system  composed  of  M 
modules,  the  method  examines  an  n*n  matrix  of  estimated 
probabilities,  the  (i,j)th  element  being  the  probability  that  a 
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HJ^.NSENTI 

Hansen,  W.J.;  User  Engineering  Principles  for  Interactive 
Proceedings  of  the  SJCC  36  (1971)  pp. 523-532. 


CE22,792 
Systems ; 


H;^TFIELD71 
Hatfield,  D., 


and  Gerald,  J. ;  Program  Eestructur ing  for 


Memory;  lEM  Systems  Journal  10,3  (1971)  pp. 168-192. 


CE23,271 
Vi rtual 


Much  effort  has  been  directed  of  late  to  the  improvement  of 
problem-program  performance  on  virtual  memory  systems.  This  paper 
describes  a  procedure  for  determining  the  memory-use 
characteristics  of  a  program  and  then,  through  a  combination  of 
automatic  and  manual  algorithms  and  heuristics,  rearranging  the 
code  tc  improve  paging  behavior.  The  method  described,  as  opposed 
to  many,  is  practical,  in-use,  and  results  in  a  (typically)  5  to  1 
improvement. 


HENDEESCN72 
Henderson,  P.,  and 
Programming;  EIT  12 
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HENDEY71 

Hendry,  D.;  Benefits  For  User  and  Producer  of  an  Engineering 
Approach  to  Compiler  Design;  in  Hugo,  J.S.  (ed.).  The  Fourth 
Generation .  Infotech,  Ltd.,  Berkshire,  England  (1971)  pp. 299-312. 


HINRICKSEH72 

Henricksen,  J.O.,  and  Merwin,  E.E.; 
Efficiency  in  Beal-Time  Software  Systems; 
4C  (1972)  pp. 155-161. 
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HILL72 

Hill,  I.D.;  Wouldn't  it  be 
programs  in  ordinary  English 
16,6  (June  1972)  pp. 306-312 


nice  if  we  could  write  computer 
-  or  would  it?;  The  Computer  Bulletin 


A  somewhat  weak  attempt  to  argue  that  "ordinary  English"  could 
never  be  used  as  a  programming  language,  since  its  intricacies  are 
beyond  our  ability  to  translate  -  "can  anyone,  today,  even  begin 
to  think  hew  to  write  [a  program  to  understand  ordinary  English]?" 
Although  the  author  provides  an  amusing  demonstration,  with  many 
examples,  of  the  (obvious)  fact  that  English  abounds  with 
ambiguities,  he  seems  not  to  be  aware  that  there  is  such  a 
discipline  as  Artificial  Intelligence,  which  in  fact  concerns 
itself  (realistically)  with  natural  language  understanding 
systems.  Less  shakily,  he  argues  that  even  if  we  had  such  a 
programming  system,  we  would  lose  much  of  the  unambiguous 
precision  which  we  have  grown  to  expect  from  a  computer  -  and  he 
proposes  that  a  more  useful  development  would  be  the  introduction 
of  a  precise,  algorithmic  language  for  human  communication  (of 
instructions)  . 


HCARE71a  CE23,647 

Hoare,  C.A.E.;  Procedures  and  Parameters:  An  Axiomatic  Approach; 
Symposium  on  Semantics  of  Algorithmic  Languages,  Springer  Verlag, 
Berlin  (1971)  pp. 102-116. 

The  author  develops  a  formalism  which  facilitates  proofs  of 
program  correctness.  He  needs  to  impose  a  restriction  on 
procedure  calls,  which  is,  however,  a  desirable  programming 
feature . 


HCAEE71b 
Hcare  ,  C.A. R.  ; 
pp. 39-45. 


Proof  of  a  Program:  FIND;  CACM  14,1 


CE22,296 
(January  1971) 


An  ijl^ortant  non-trivial  example  of  concurrent  program 
construction  and  proof  of  correctness.  Hoare  mentions  some 
disadvantages  and  weaknesses  to  this  approach,  but  he  obviously 
feels  that  such  formal  proofs  are  extremely  important  and  that 
eventually  computer  assistance  may  be  possible. 


HCAEE72a 

Hcare,  C.A.R.;  Notes  on  Data  Structuring;  in  Dahl,  O.J.,  Eijkstra, 
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E.W.  ,  and  Hoare,  C.A.P.;  Structured  Programming;  Academic  Press, 
New  York  (1972)  pp. 83-174. 


The  author  motivates  the 
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examples.  Within  this  settin 
special  attention  devoted  to 
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meaning  of  the  structures,  and 
ions  of  values  of  the  structures.  An 
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HCARE72b  CP,25,944 
Hcare,  C.A.P. ;  Towards  a  Theory  of  Parallel  Programming;  in  Hoare, 
C.A.R.  and  Perrott,  P.H.(eds.),  Operating  Systems  Techniques, 
Academic  Press,  N.Y.  (1972)  pp. 61-71. 

This  paper  begins  with  a  brief  discussion  of  objectives  to  be  met 
in  designing  a  parallel  processing  feature  for  high-level 
language:  compile-time  checks  to  avoid  time-dependent  errors, 
generation  of  efficient  code,  and  constructs  which  are  both 
conceptually  simple  and  widely  applicable. 

Constructs  are  proposed  for  defining  parallel  processes,  defining 
resources,  and  using  them  for  interprocess  communication.  These 
constructs  appear  to  satisfy  the  stated  objectives  quite  well, 
although  the  notation  for  the  first  seems  rather  difficult  to  read 
and  prone  to  ceding  errors;  the  semantics  of  the  third  allow  a 
definite  possibility  for  "busy-waiting, "  something  which  might  be 
avoided  by  a  more  sophisticated  enqueuing  of  blocked  processes  on 
conditions  rather  than  on  simple  resource  availability. 

Two  other  useful  concepts  are  introduced;  the  capability  of 
partitioning  arrays  to  allow  simultaneous  access  by  more  than  one 
process,  and  the  ability  to  define  arrays  of  resources. 


HCARE72C 

Hoare,  C.A.R.;  Proof  of  Correctness  of  Data  Representation;  Acta 
Inf or matica-I ,  Sprin ger- Ver lag  (1972)  pp. 271-281. 

Hcare  proposes  that  one  should  develop  algorithms  with  abstract 
data  concepts,  and  choose  a  representation  for  the  data  after  the 
design  is  finished.  In  this  paper  he  discusses  the  problem  of 
proving  that  the  concrete  representation  chosen  actually  performs 
tc  the  requirements  of  the  abstract  concept.  He  uses  the 
methodology  of  SIMULA  data  constructs  and  provides  a  small  example 
proof . 


HCARE73a 

Hoare,  C.A.R.;  Hints  on  Programming  Language  Design;  ACM  Symposium 
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on  the  Principles  of  Programming  Languages,  Boston  (October  1973) 
pp , 1 -  30. 

This  highly  readable  and  frequently  entertaining  article  begins 
with  the  observation  that  "a  programming  language  is  a  tool  which 
should  assist  the  programmer  in  the  most  difficult  aspects  of  his 
art,  namely  program  design,  documentation  and  debugging." 

In  this  context,  Hoare  reflects  cn  numerous  language  and  compiler 
features.  He  argues  that  a  good  language  should  encourage  simple 
and  readable  programs,  and  have  a  fast  compiler  which  can  produce 
secure  and  efficient  code.  He  suggests  that  a  good  many  of  the 
newer  languages  may  actually  irake  the  programmer’s  task  more 
diff icult . 

One  is  reminded  that  an  extremely  important  part  of  the  design 
process  is  the  decision  of  what  to  omit,  an  aspect  which  appears 
rarely  to  have  received  adequate  attention. 


HC?.RE73b 

Hoare,  C.i^.E.;  Recursive  Data  Structures;  Stanford  University, 
Computer  Science  Dept.,  STAN-CS-73-400  (October  1973)  pp.1-32. 

The  author  proposes  an  extension  to  programming  languages  to  allow 
data  structures  to  be  defined  by  recursion.  The  formalism  is  to 
define  a  "type"  in  terms  of  a  recursive  application  of 
"generators"  over  a  type  list.  Manipulation  of  these  structures 
is  confined  to  further  applications  of  the  generators  on  instances 
of  the  defined  type. 

The  claim  is  made  that  such  a  schema  would  eliminate  the  problems 
associated  with  the  FL/1  or  ^.lgol68  pointer  type.  The  pointer 
type  is  cited  as  the  data  structures  equivalent  of  the  "go  to"  in 
control  structures. 

The  author  goes  on  to  define  his  new  construct  in  an  axiomatic 
fashion  and  to  suggest  implementation  methods. 


HC;i.RE73c 

Hoare,  C.A.R.,  and  Wirth,  N. ;  An  Axiomatic  Definition  of  the 
Programming  Language  PASCAL;  Acta  Informatica  2  (1973)  pp. 335-355. 

An  attempt  to  describe  formally  the  semantics  of  the  language 
PASCAL.  The  basis  for  this  is  the  approach  expounded  in  "An 
Axiomatic  Basis  for  Computer  Programming"  [HOARE69].  The 
definition  is  quite  useful  but  it  is  incomplete:  some  language 
features  were  left  out  and  some  restrictions  were  made.  These 
omissions  seem  to  be  due  to  complexity  and  point  to  parts  of  the 
language  worth  considering.  The  omissions  include:  real 
arithmetic,  GC  TCs,  ALPHA-type.  The  following  features  are 
imperfectly  described:  classes,  procedures  and  functions  with 
regard  to  global  variables.  This  document  does  not  replace  the 
original  defining  report,  it  only  supplements  it. 
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HC;^RE74 

Hcare,  C.A.E.;  Monitors:  an  Operating  System  Structuring  Concepts; 
C;^.CM  17,10  (October  1974)  pp.  549-557. 


This  paper  presents  a  very  good  description 
defined  and  applied  to  a  number  of  practical 
systems.  Various  details  are  discussed, 
nature  of  the  "condition  variable,"  proof 
stated  for  monitors,  and  how  a  monitor  ma 
semaphores.  (This  last  is  rather  confusing, 
semaphore  operations  are  stated  explicitly) , 
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KCLT73a 

Holt,  P.C.;  Teaching  the  Fatal  Disease  (or)  Introductory  Computer 
Programming  Using  PL/I;  SIGPLP'N  Notices  8,5  (May  1973)  pp.8-23. 

The  author  makes  plentiful  use  of  humour  and  examples  to  support 
his  dual  claim  that  PL/I  is  a  good  language  to  use  in  teaching 
introductory  programming  (or  implementing  computer  systems)  but 
that  successful  use  of  PL /I  depends  upon  restricting  oneself  to  a 
small  subset  of  the  language.  He  claims  that  to  successfully  teach 
(or  use)  structured  programming  technigues,  one  must  write 
programs  in  a  small  language  tha-^  can  be  completely  mastered.  The 
rules  he  suggests  for  subsetting  the  language  restrict  control 
constructs  to  a  structured  set,  and  restrict  data  types  to  avoid 
the  messy  conversion  and  precision  rules. 


HCLT73k 

Holt,  R.C.  and  Wortman,  C.E.;  Structured  Subsets  of  the  PL/I 
Language;  Technical  Report  27,  Computer  Systems  Research  Group, 
University  of  Toronto  (October  1973)  pp.1-27. 

This  paper  presents  a  sequence  of  subsets  of  the  PL/I  language 
developed  by  the  authors  for  the  purpose  of  teaching  introductory 
programming.  The  subsets  are  based  on  the  thoughts  given  in 
"Teaching  the  Fatal  Disease"  cn  taming  PL/I  for  teaching 
structured  programming.  A  iescription  of  the  University  of 
Toronto's  SP/k  compiler  which  enforces  use  of  the  subsets  is 
given . 


HCLT75 

Holt,  R.C.  ;  Structure  of  Computer  Programs:  a  Survey;  Proceedings 
of  the  IFFE  63,6  (June  1975)  pp. 879-893. 


The  author  examines  the  reasons  and  methods  for  dividing  "large" 
programs,  ooncent rating  on  overall  external  program  structure, 
rather  than  internal  control  structures.  He  describes  the  focus 
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of  the  paper  as  "The  Organization  of  Software",  and  perhaps  this 
would  have  been  a  more  appropriate  title. 

The  author  states  that  program  division  is  due  to  both  hardware 
constraints  (limited  memory,  excessive  running  time,  etc.)  and 
human  constraints  (delegation  of  programming,  better 
under standability,  etc.).  The  method  of  division  -  functional 
decomposition  -  is  seen  to  best  follow  a  top-down  approach.  He 
then  considers  "Mechanisms  for  Program  Composition"  -  that  is, 
tools  for  combining  smaller  pieces  into  a  complete  program  such  as 
parameter  passing,  shared  data  and  synchronous  interactions.  Some 
of  this  portion  of  the  discussion  is  at  the  operating  system 
level,  with  discussions  of  program  linkage,  traps  and  interrupts, 
and  may  prove  too  complex  for  the  "average"  programmer.  This 
portion  of  the  article  also  considers  coroutines  and  discusses 
possible  interactions  using  semaphores  and  mailboxes. 

Finally,  he  considers  program  "folding"  due  to  memory  limitations, 
describing  three  methods  -  overlays,  segmentation  and  paging  -  and 
the  effects  on  programs  of  each. 


HCPKINS71 

Hopkins,  M.;  Problems  of  PL/I  for  Systems  Programming;  SIGPLAN 
Notices  6,9  (1971)  pp. 89-91. 
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description  by  an  lEM  project  head  of  the  implementation 
antial  system  in  PL/I.  Aside  from  mentioning  the  many 
or  inefficient  PL/I  constructs  and  the  difficulty  of 
a  good  compiler,  Hopkins  points  out  that  programming  in 
vel  language  often  leads  to  more  efficient  systems 
the  understandable  nature  of  the  source  code.  He  claims 
modules  are  poorly  implemented  the  first  time,  and  that 
gained  is  often  not  put  to  use  because  of  the  natural 
to  tamper  with  a  "working"  program.  Not  a  great  paper, 
pages  it' s  worth  your  time. 


HCPKINS72 

Hopkins,  M.E.;  The  GOTO  Controversy:  A  Case  for  the  GOTO;  SIGPLAN 
Notices  7,11  (November  1972)  pp. 59-62. 

Because  the  GOTO  Controversy  seems  totally  dead  (at  least  in  an 
university  environment)  as  a  result  of  overwhelming  opposition  to 
the  construct,  this  paper  makes  good  reading.  It  points  out  many 
reasons  for  retaining  the  GOTO  in  modern  programming  languages. 
The  major  emphasis  is  on  the  fact  that  programming  without  GOTO's 
does  not  imply  good  "structured"  programming,  neither  does  the 
presence  of  the  GOTO  imply  badly  structured  programming,  in  fact, 
many  people  in  trying  to  eliminate  the  construct,  lose  sight  of 
the  ultimate  goals. 


HCENING74a 

Horning  J.J.;  What  the  Compiler  should  tell  the  User,  in  "Compiler 
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Ccnstruction :  An  Advanced  Course,"  F.L.  Eauer,  Editor,  Springer- 
Verlag,  Berlin  (1974)  pp. 525-548. 

An  excellent  article  which  should  be  read  by  anyone  who  is 
starting  to  write  a  compiler.  It  describes  the  needs  of  the 
programmer  who  will  be  using  the  compiler,  emphasizing  the  fact 
that  all  programs  have  errors  in  them  when  they  are  first  written. 
The  fast  development  of  correct  programs  requires  an  intelligent 
scluticn  to  the  problems  of  error  detection,  diagnosis,  and 
documentation  by  the  compiler  so  that  the  user  may  easily  discover 
his  mistakes.  Output  should  be  in  language  understandable  by  the 
user  (who  should  not  be  expected  to  knew  compiler  jargon) .  In 
fact,  for  anyone  writing  a  program  to  be  used  by  someone  else, 
this  article  could  be  used  as  a  guide  to  what  should  appear  in  the 
program  output.  Perhaps  a  better  title  would  be  "What  the  Program 
Should  Tell  the  User." 


HCBNING74b 

Horning,  J. J. ,  Lauer,  H.C.,  Melliar-Smith ,  P.M.,  and  Pandell,  B.; 
A  Program  Structure  for  Error  Detection  And  Recovery;  University 
of  Newcastle  Upon  Tyne,  Computing  Laboratory,  Technical  Report  59 
(April  1974)  pp.1-16. 


This  paper  presents  a  structured  formalism  and  an  associated 
recovery  machine  for  dealing  with  hardware  and  software  errors. 


on  the  premise  that  error  detection  and  recovery  is  useful,  the 
authors  develop  the  "Recovery  Block"  construct  which  includes  the 
intended  operation,  a  testing  mechanism,  and  an  associated  set  of 
"alternative  blocks."  "Recovery  blocks"  can  be  nested  (and 
structured) .  This  suggests  a  stack-like  mechanism  be  used  to  keep 
track  of  variables  (and  pathways)  for  recovery.  The  authors 
present  the  "recursive  cache"  as  a  reasonable  implementation  of 
such  a  mechanism.  The  "recursive  cache"  only  keeps  track  of 
changed  (written)  variables.  Recovery  proceeds  by  restoring  all 
changed  "recovery  block"  variables  and  entering  an  appropriate 
"alternative  block." 


A  more  complex  form  of  this 
proposed  for  recovery  from  th 
involving  operations  other  t 
seme  ongoing  implementation  e 
error  recovery  design  in  soft 


scheme,  "recoverable  procedures,"  is 
e  more  typical  systems  environment, 
han  assignment.  The  authors  indicate 
fforts.  (Perhaps  the  significance  of 
ware  systems  is  understated.) 


ICKEIAH73 

Ichbiah,  J.D.,  Rissen,  J.P.,  and  Heliard,  J.C.;  The  Two-Level 
Approach  to  Data  Independent  Programming  in  the  LIS  System 
Implementation  Language;  Proceedings  of  the  IFIP  TC-2  Conference 
on  Machine-Oriented  High-Level  Languages  (1973). 

This  paper  describes  a  two- level  approach  to  defining  data 
structures  which  permits  separation  of  the  semantic  properties  of 
data  from  their  effective  implementation.  "implementation  parts" 
are  provided  for  specification  of  low-level  features  of  a 
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structure  when  machine  d 
semantic  implications  of 
conclude  that  LIS  user 
language  with  typecheck 
programs  is  facilitated 
in  implementation  parts. 


ependencies  so  require.  The  syntactic  and 
this  feature  are  discussed.  The  authors 
s  enjoy  the  advantages  of  a  high-leve 
ing,  and  that  transferability  of  LI 
by  the  isolation  of  machine-dependencies 


k;^.HN71 

Kahn,  G. ;  An  Approach  to  System  Correctness;  Proceedings  of  the 
Third  ACM  Symposium  on  Operating  Systems  Principles  (October  1971 ) 
pp . 86- 94 . 


Dealing  with  systems  of  a  finite  number  of 
discusses  several  approaches  to  describing  a 
its  correctness.  As  usual,  success  is  c 
methods  when  they  are  shown  capable  of  dealin 
examples;  in  this  case  semaphores 
philoscphers/slippery  spaghetti  problem. 
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KEBNIGHAN74 
Kernighan,  E.W., 
Counterexamples; 


CE28, 103 

Plauger,  P.J.;  Programming  Style;  Examples  and 
Computing  Surveys  6,4  (December  1974)  pp. 303-319. 
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a  survey  of  some  aspects  of  programming  style.  It 
xamples,  that  programs  written  with  good  style  are 
and  understand,  and  often  smaller  and  more 
those  written  badly.  The  authors  discuss  various 
from  programming  text  books,  and  illustrate  the 
prove  these  example  programs.  Throughout,  the 
mostly  about  expression  and  structure,  with 
ressions  on  robustness,  efficiency  and 


KEEPELMAN71  CE22,446 
Kerpelman,  C.;  Clarification  of  FOETBAN  Standards  Second  Beport; 
CACM  14,10  (October  1971)  pp. 628-642. 

A  revision  of  the  first  FOETBAN  standards  report  is  presented 
clarifying  ambiguities,  specifying  definitions  omitted,  correcting 
errors  and  discussing  additions  and  extensions  to  the  standards 
and  language.  The  article  would  be  of  major  interest  only  to 
specialists  as  it  is  extremely  detailed  and  low  level;  however  it 
serves  as  a  good  example  of  standardization  and  documentation 
problems  that  occur  in  any  attempt  at  precise  language  definition. 
Well  written  and  easily  understood  because  of  its  nature  and 
format . 


KIMELFT0N72  CE23,879 
Kimbleton,  S.B.;  Performance  Evaluation  -  A  Structured  Approach; 
Proceedings  of  the  SJCC  40  (1972)  pp. 411-416. 
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This  paper  is  ccncerned  with  evaluating  the  performance  of  a 
computer  system,  including  its  o^er^ina  system.  Although  directed 
towards  evaluation  for  purposes  of  selection  and  comparison,  the 
ideas  presented  are  relevant  with  regard  to  the  improvement  or 
evaluation  of  a  particular  programming  or  operating  system  for  a 
particular  machine.  In  particular,  the  point  is  made  that  usually 
a  few  key  variables  drive  the  entire  system. 


KING71 

King,  J.C.;  Proving  Programs  to  be  Correct;  lEZE  Transactions  on 
Computers  C-20,11  (November  1971)  pp . 1 33 1 - 13 36 . 


KNUTH71a 

Knuth,  D.E.,  and  Floyd,  F.E.;  Notes  on  Avoiding  "go  to" 
Statements;  Information  Processing  Letters  1,1  (February  1971) 
pp. 23-31 . 

This  paper  discusses  the  use  of  the  "goto"  statement  and  methods 
of  avoiding  them.  The  "goto"  statement  can  be  replaced  by  a 
procedure  call,  or  a  program  segment  containing  a  "goto"  can  be 
imitated  by  using  an  iterative  loop.  The  methods  are  applied  to 
two  typical  programming  examples:  symbol  table  searching  and 
backtracking.  The  article  discusses  when  certain  methods  are 
desirable  and  when  they  would  only  add  ambiguity  to  the  program. 


KNUTH71b  CF2 
Knuth,  D.E.;  An  Empirical  Study  of  FORTRAN  Programs;  Softwa 
Practice  and  Experience  1,2  (April/June  1971)  pp.  105-133. 


This  paper  deals  with  a  study  of  a  sample  of  programs  writt 
FORTRAN  by  a  wide  variety  of  people  for  a  wide  variet 
applications.  Statistical  results  of  the  study  are  present 
the  paper,  together  with  seme  of  their  apparent  implications 
future  work  in  compiler  design.  The  principal  conclusion 
may  be  drawn  is  the  importance  of  a  table  of  frequency  c 
which  record  how  often  each  statement  is  performed  in  a  ty 
run.  With  the  table  of  frequency  counts,  a  programmer  o 
optimizing  compiler  may  optimize  a  program  by  merely  optim 
those  portions  of  the  program  which  are  executed  most  freque 
and  thus  reduce  the  amount  of  time  spent  in  producing  effi 
programs. 
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KNDTH73a 

Knuth,  D.E.;  A  Review  of  Structured  Programming ;  Stanford 
University,  Department  of  Computer  Science,  Technical  Feport  STAN- 
CS-73-371  (June  1973) . 

This  report  contains  a  detailed  review  of  the  book  Structured 

"the  form  of  letters  to  each  of  the  three  authors 
(Dahl,  Dijkstra,  and  Hoare) .  Each  letter  is  opened  with  very 
flattering  compliments  to  the  author,  and  then  discusses,  in  a 
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pcint  by  point  fashion,  many  (sometimes  minute)  details  of  that 
author's  chapter  in  the  book. 

Knuth's  points  are  too  numerous  to  list.  They  are  often 
ccntrcversial ,  inspiring  one  to  reread  portions  of  the  book  to 
refresh  his  memory  and  "take  sides."  Especially  interesting  is 
Knuth's  application  of  Simula  classes  (from  Dahl's  chapter)  to  a 
problem  which  Dijkstra  solves  in  his  chapter. 


KNUTH73b  CE25,533 
Knuth,  D.E.;  The  Art  of  Computer  Programming  -  V 3/Sor ting  and 
Searching;  Addison-Wesley  (1973)  pp.722. 


This  book  is  an  excellent  survey 
and  searching  techniques  (chap 
elementary  technigues  of  inter 
"optimum"  sorting  techniques, 
techniques,  with  a  brief  word  on 
searching,  he  covers  several 
including  Fredkin's  TEIE,  as 
techniques,  some  of  which  prove  u 
keys,  a  tcpic  of  current  interest 
analysis,  Knuth' s  presentation  s 
reliance  on  MIX,  an  assembler  1 
an  imaginary  machine. 


of  sorting  techniques  (chapter  5) 
ter  6) .  The  author  covers 
nal  sorting  as  well  as  various 
He  covers  many  tape  sorting 
disk  sorting.  In  the  chapter  on 
tree  representation  techniques, 
well  as  several  hash  coding 
seful  for  retrieval  on  secondary 
when  associated  with  "data  base" 
eems  weakened  a  little  by  his 
anguage  of  his  own  derivation  for 


KNUTH74 

Knuth,  D.E.;  Structured  Programming  with  go  to  Statements; 
Computing  Surveys  6,4  (December  1974)  pp. 261-301. 

An  important  and  controversial  paper.  No  matter  what  one's 
opinion  of  this  paper  is,  one  will  have  had  to  have  read  it  if  one 
wishes  to  discuss  structured  programming.  It  has  a  nice 
bibliography  as  well. 


KCSINSKI73 

Kosinski,  P.E.;  A  Data  Flow  Programming  Language;  IBM  EC  4264 
(March  1973)  pp. 1-134, 

A  two  dimensional  Data-flow  language  devised  by  the  author  is 
described.  This  language  has  the  property  of  having  no  variables, 
and  no  control  flow  primitives.  Although  the  language  is  not  very 
useful,  the  ideas  involved  are  interesting. 


KDLSEDr74 

Kulsrud,  K.E,;  Some  Statistics  on  Reasons  for  Compiler  Use; 
Software  -  Practice  and  Experience  4,3  (July-September  1974) 
pp. 241-249. 

This  paper  describes  a  distribution  of  Compiler-time  usage.  Eased 
on  a  statistical  survey,  the  author  reports  user's  time  used  in 
program  writing,  program  correction,  program  checking  etc.  The 
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languages  used  in  the  survey  are  FOETEAN  and  IMP.  No  concrete 
conclusions  are  given  but  it  may  lead  to  further  investigations  in 
the  area  cf  "tetter  programming  languages." 


LA  FRANCE? 1 

LaFrance,  J.E.  ;  Syntax-directed  Error  Recovery  for  Compilers;  Ph. 
D.  Thesis,  University  of  Illinois  at  Urbana-Champaign ,  Department 
cf  Computer  Science  (1971)  pp. 1-162. 

This  thesis  presents  a  system  of  automatic  error  recovery  for 
syntax  directed  parsing  algorithms  which  is  based  solely  on  the, 
syntax  of  the  language.  This  method  is  not  only  automatic, 
reguiring  no  additional  effort  from  the  language  designer  beyond 
the  syntactic  specification  of  his  language,  but  it  also  is  much 
more  effective  than  most  hand  written  systems.  In  a  set  of 
programs  run  on  four  different  compilers  constructed  using  this 
system,  only  six  cut  of  140  errors  were  missed  and  92  out  of  the 
134  errors  detected  were  described  to  the  programmer  exactly.  In 
only  nine  cf  the  134  detected  errors  was  the  message  about  the 
error  apt  to  be  confusing. 


LAMPSON71 

Lampson,  E.N.;  Cn  Reliable  and  Extendable  Operating  Systems;  in 
Hugo,  J.£.  (ed.) ,  The  Fourth  Generation,  Infotech,  Ltd., 
Berkshire,  England  (1971)  pp. 421-444. 


LANDY71  CP22,447 
Landy,  E. ,  and  Needham,  E.M.;  Software  Engineering  Technigues  used 
in  the  Development  of  the  Cambridge  Multiple-Access  System; 
Software- Practice  and  Experience  1,2  (April-June  1971)  pp. 167-173. 

Testing  and  development  cf  elaborate  systems  requires  the 
assistance  of  sophisticated  technigues  and  software  aids  at 
several  stages  in  the  process.  These  include  systems  for  managing 
and  manipulating  source  text,  producing  and  testing  new  versions 
in  a  realistic  but  "safe"  environment  and  arranging  for  easy  and 
compatible  fall-back  process  to  a  previous  version  in  case  of 
unforeseen  difficulties.  The  paper  describes  a  number  of  such  aids 
that  have  been  found  useful  during  the  development  of  the 
Cambridge  Multiple-Access  system. 


LANZAECNE72 


Lanzarone,  G.A.; 
Computer  Journal 
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6,1  (1972)  pp.38 
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LASSETTRE72  CR24,594 
Lassettre,  E.R.,  and  Scherr,  A.L.;  Modelling  the  Performance  of 
the  OS/360  Time-Sharing  Option  (TSO)  ;  in  Freiberger,  W.  (ed.)  , 
Statistical  Computer  Performance  Evaluation,  Academic  Press  (1972) 
pp.  57-72 . 

When  properly  handled,  modelling  can  be  an  invaluable  tool  in  the 
design  of  a  performance-bound  software  system.  This  paper 
describes  an  extremely  successful  application  of  modelling  to  the 
design,  debugging  and  modification  of  a  fairly  complex  operating 
system . 

Measurements  taken  during  the  implementation  of  TSO  were 
continually  compared  to  the  predictions  of  the  model,  a  reasonably 
simple  analytical  one  calibrated  and  driven  by  observations  of 
other  systems.  The  "accuracy”  of  the  model  was  such  that 
perfomance  discrepancies  were  usually  traced  to  bugs  in  TSO 
itself.  The  model  thus  served  at  least  two  purposes:  early 
prediction  of  ultimate  performance,  and  identification  of 
performance  problems  during  implementation. 


LEAVENW0ETH72  CR24,148 
Leavenworth,  E.M.;  Programming  With  (out)  the  GOTO;  Proceedings  of 
the  ACM  1972  Annual  Conference  (1972)  pp. 762-786. 

The  author  presents  a  brief  history  of  the  GOTO  controversy.  The 
GOTO  does  not  appear  in  formal  systems  such  as  the  Post  system  or 
Kleene  general  recursive  functions,  but  has  been  added  to 
programming  languages.  The  existence  of  the  GOTO  as  a  primitive 
operation  on  machines  has  influenced  the  design  of  high  level 
languages.  The  author  summarizes  both  sides  of  the  argument.  In 
its  favor,  the  GOTO  is  needed  for  abnormal  exits  from  blocks  or 
procedures,  efficient,  useful  for  synthesis  purposes.  However, 
programs  without  GOTOs  are  more  easily  understood,  debugged,  and 
modified.  It  is  easier  to  prove  assertions  about  programs  which 
contain  no  GOTOs.  Finally,  the  GOTO  is  frequently  misused  to 
synthesize  more  sophisticated  control  structures. 


LESTER71 

Lester,  E.P.;  Cost  Analysis  of  Debugging  Systems;  MIT,  Project 
MAC,  TR-90  (September  1971)  pp. 1-112. 


IISK0V72  CR25,795 
Liskov,  E.H.;  A  Design  Methodology  for  Reliable  Software  Systems; 
Proceedings  of  the  FJCC  41  (1972)  pp. 191-199. 


This  paper  presents  a  methodology  for  the  development  of  reliable 
software.  It  begins  by  justifying  the  development  of  such  a 
methodology  in  light  of  the  failure  of  existing  methods  (involving 
extensive  debugging)  to  produce  reliable  software.  The  author 
then  describes  a  two-part  methodology  derived  from  her  own 
experience  with  a  large  software  project. 
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The  first  part  involves  the  definition  of  a  "good"  system 
modularization,  in  which  the  system  is  organized  into  a  hierarchy 
of  "partitions"  each  corresponding  to  a  level  of  abstraction,  and 
having  minimal  connections  with  one  another.  The  total  system 
design  is  then  expressed  as  a  structured  program,  rendering  the 
design  amenable  to  existing  proof  tichnigues. 

The  second  part  looks  at  the  guestion  of  how  to  achieve  a  system 
design  with  good  modularity.  The  key  to  the  design  is  seen  by  the 
author  as  the  identification  of  "useful"  abstractions  which  help 
the  designer  to  think  about  the  system.  Some  techniques  for 
findirg  such  abstractions  are  given.  A  definition  of  "end  of 
design"  is  given,  involving  having  a  system  design  with  the 
desired  structure,  and  a  preliminary  user's  guide. 

The  paper  ends  by  describing  experiments  in  the  use  of  the 
methodology  in  progress  at  the  time  of  presentation. 


LISKOV73 
Liskov,  B.; 
Notices  8,9 


Report  of  Session  on  Structured 
(September  1 S73)  pp.5-10. 


Programming;  SIGPLAN 


An  overview  of  the  definition  of  structured  programming  is  given, 
including  levels  of  abstraction,  abstract  data,  etc.  The 
discussion  includes  sections  on  monitors,  protection,  and 
construction  of  structured  programs  as  well  as  linguistic  features 
which  should  be  provided  by  a  structured  programming  language. 


LISKOV74 

Liskov,  B.H.,  and  Zilles,  S.;  Programming  with  Abstract  Data 
Types;  Proceedings  of  the  Symposium  on  Very  High  Level  Languages, 
SIGPLAN  Notices  9,4  (April  1974)  pp. 50-59. 
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These  features  are  illustrated  using  programming  examples.  The 
syntax  seems  slightly  awkward,  but  the  authors  assert  that  the 
awkwardness  enhances  understandability .  The  paper's  relationshi 
to  previous  work  is  reviewed,  and  implementation  consideration 
are  discussed. 
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LCND0N71 

London,  E.I.;  Experience  with  Inductive  Assertions 
Programs  Correct;  In  Engler,  E.  (ed)  ;  Symposium  on 
Algorithmic  Languages;  Springer-Verlag,  Berlin  (1971) 


for  Proving 
Semantics  of 
pp. 236-251 . 


The  author  discusses  and  gives  examples  of  the  inductive  assertion 
method  cf  proving  programs  correct.  He  gives  examples  of  both  the 
forward  accumulation  and  backward  substitution 
verifying  assertions  using  a  particular  type  of 
representation.  He  also  looks  at  two  attempts 
automatic  correctness  provers. 


methods  of 
assertion 
to  develop 


LCCAS71  CE23,420 
Lucas,  H.C.;  Performance  Evaluation  and  Monitoring;  Computing 
Surveys  3,3  (September  1971)  pp. 79-91. 


LUCAS73 

Lucas,  H.C.,  and  Presser,  L. ;  A  Method  of  Software  Evaluation:  the 
Case  of  language  Translators;  The  Computer  Journal  16,3  (August 
1973)  pp. 226-231. 

This  paper  presents  a  method  of  evaluating  software,  in 
particular,  language  translators.  A  set  of  14  characteristics  for 
quantitative  comparison  of  language  translators  is  given.  The 
design  of  synthetic  benchmark  programs  to  evaluate  some  cf  these 
characteristics  is  described.  In  the  specific  evaluation  example 
given,  the  evaluation  concludes  that  WATFIV  is  superior  to  IBM 
FCETRAN  G  or  H,  in  an  installation  where  much  time  is  spent 
debugging  -  net  a  very  profound  result.  Hew  to  perform  an 
evaluation  along  similar  lines,  where  the  specifications  are  not 
as  well-defined,  or  where  the  software  is  not  both  finished, 
debugged,  and  available  for  use,  or  where  a  decision  must  be  made 
between  two  available  programs  with  different  specifications,  is 
net  clear  from  this  paper. 


LYLE7  1 

Lyle,  D.M.;  A  Hierarchy  of 
Programming;  SIGPLAN  Notices 


High  Order  Languages  for  Systems 
6,  9  (1971)  pp. 73-78. 


MANACHEE71 


Manacher,  G.K.;  Some  Design  Principles  for  High  Level  Systems 
Programming  Languages;  University  of  Chicago,  Institute  for 
Computer  Research,  ICR  Quarterly  Report  25  (May  1971)  pp.1-17. 


The  attributes  of  high-level  languages  (e.g.,  PL/I,  CPL) 
cf  low-level  languages  (BCPL,  L6,  PL360)  are  listed.  A  co 
of  these  two  lists  is  taken  as  the  design  strategy  f 
language  with  high-level  convenience  (phrase  structure 
block  structure,  extensibility,  protection,  and  control) 
level  features  (machine-dependent  data  specification, 
access,  system-quality  code  emitted) .  The  criteria  are 
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the  discussion  on  how  much  of  any  feature  is  desirable  is  not 
exhaustive. 

M;^NN;^71  CE23,686 
Manna,  Z.,  and  Waldinger,  R.J.;  Toward  Automatic  Program 
Synthesis;  CACM  14,3  (March  1971)  pp. 151-165. 


MANNA73 
Manna  ,  Z . , 
Properties 


Ness,  S.,  Vuillemin,  J. ;  Inductive  Methods  for  Proving 
of  Programs;  CACM  16,8  (August  1973)  pp. 491-502. 
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MAEC0TTY74  CR27,168 
Marcotty,  M.,  Schultz,  H. ;  The  Systems  Programming  Language  MALUS ; 
Software  -  Practice  and  Experience  4,1  (January-March  1974)  pp.79- 
90. 

MALUS,  a  dialect  of  PL/I  and  an  outgrowth  of  XPL  is  described.  It 
is  a  compiler  which  can  compile  itself,  and  has  been  used  at  CDC 
tc  implement  a  multi-console  time  sharing  system  (MCTS)  on  the 
STAR- 100  and  STAR-65  computers.  Their  success,  as  described  under 
"evaluation, ”  may  well  spell  the  doom  of  assembly  languages  for 
the  implementation  of  operating  systems,  for  the  instruction  set 
for  the  STAR  computer  is  very  complicated  indeed,  yet  the  authors 
did  net  feel  restricted  by  their  use  of  a  high-level  language  tc 
implement  a  timesharing  operating  system. 


MARG01IN72 

Margolin,  E.H.,  Parmelee,  R.P.,  and  Schatzoff, 
Free  Storage  Algorithms;  in  Freiberger,  W. 
Computer  Performance  Evaluation,  Academic  Press 


M.;  Analysis  of 
(ed.),  Statis tical 
(1972). 


A  description  of  an  excellent  melding  of  system  measure 
statistical  techniques,  modelling  and  experiment  design 
resulted  in  a  substantial  improvement  in  the  CP-67  oper 
system.  Highly  recommended  to  those  interested  in  banging  exi 
software  into  shape. 

MARTIN74 

Martin,  J.J.;  Generalized  Structured  Programming;  AFIPS  Cenfe 
Proceedings  43  (1974)  pp. €65-669. 

This  paper  is  of  interest  to  all  who  have  read  any  of  Dijks 
papers  on  structured  programming.  Martin  is  suggesting 

currently  accepted  structured  programming  constructs 

generalized.  It  is  the  author's  claim  that  Dijkstra's  const 
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are  too  restrictive,  and  actually  lower  program  understandability 
through  the  necessity  of  programming  steps  "that  are  motivated 
sclely  by  structural  restrictions  imposed  by  rules  of  style.”  The 
author  cites  particularly  that  Dijkstra*s  constructs  reguire  undue 
progran  complexity  to  compute  complex  conditions,  since  the  use  of 
condition  flags  is  often  reguired. 

To  correct  this  handicap  Martin  proposes  a  new  set  of  constructs 
which  form  a  superset  of  Eijkstra's,  The  claim  is  made  that  the 
main  advantage  of  structured  programming,  program  decomposabi lity , 
is  not  lost  with  this  expanded  construct  set.  To  make  these  new 
constructs  clearer,  actual  language  syntax  of  new  statement  types 
that  emulate  the  theoretical  constructs  is  presented. 


m;^YNABD72 

Maynard,  J,;  Modular  Programming ; 

pp. 1- 100. 


Eutterworths , 


CE23,6h5 
London  (1972) 


The  observations  of  a  professional  programmer  on  the  methods  of 
modular  programming  and  its  benefits  in  cost,  management  control, 
flexibility,  and  program  maintenance.  The  traditional  "monolithic" 
program  is  criticized  for  its  inherent  fragility  after  debugging, 
the  duplication  of  effort  involved,  and  the  mismatch  of  programmer 
talent  to  problem  that  usually  occurs.  h  step-by-step  design, 
decomposition,  and  implementation  of  a  commercial  problem,  is 
given  with  reference  to  FOBTEAN,  COBOL,  PL/I,  /360  assembler,  and 
tc  interface  methods.  The  form  of  a  module  library  for  a  software 
procedure  is  discussed. 


MCCRACKEN72  CB2U,910 
McCracken,  D.D,,  and  Weinberg,  G.M.;  How  to  Write  a  Readable 
FOBTEAN  Program;  Datamation  18,10  (October  1972)  pp. 73-77. 

Fcr  ease  of  documentation  and  for  readability,  programmers  should 
observe  the  described  rules  concerning  comments,  ”goto"s,  do- 
Iccps,  complicated  expressions,  statement  numbers  and  variable 
names . 


MCFEEMAN72 

McKeeman,  W.M.;  Compiler  Structure;  Technical  Report  23,  Computer 
Systems  Research  Group,  University  of  Toronto  (January  1973). 


MCKEEMAN74 

McKeeman,  W.M.;  Programming  Language  Design,  in  "Compiler 
Construction:  An  Advanced  Course,"  F.L.  Bauer,  Editor,  Springer- 
Verlag,  Berlin  (1974)  514-524. 

McKeeman  describes  the  levels  in  what  he  calls  the  problem  solving 
tower,  and  points  out  that  the  language  designer's  task  is  to 
facilitate  the  programming  process,  which  takes  place  at  all  of 
the  levels  of  abstraction  of  the  problem  solving  tower.  The  major 
issues  are  what  structures  are  useful  at  each  of  the  various 


-50- 


Current  /-.rticles 


levels  of  abstraction,  and  "the  new  viewpoint  is  that 
necessary  to  mix  all  the  levels  into  one  notation, 
differently,  it  was  a  mistake  to  assume  we  could  thin 
in  a  (single)  programming  language." 

Several  design  principles  and  desirable  propertie 
simplicity,  use  of  established  constructs, 
orthogonality,  adequacy,  translatability ,  and  the 
mirror  human  thought  patterns.  A  list  of  important  f 
language  not  necessary  (er  even  advisable)  to  ha 
level,  include:  assertions,  hierarchical  decomposit 
decomposition,  data  structuring,  abstraction,  seq 
manipulation,  and  redundancy.  The  Algol  languages, 
and  street  languages  are  models  used  for  the 
illustration  of  the  above  features. 

In  this  paper,  McKeeman  has  provided  an  insightful  d 
the  problem  solving  process,  and  as  such  it  is  well 
read  by  software  engineers  as  well  as  programm 
designers . 
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MI1LEF72 

Miller,  E.F.;  Eitliograpy  on  Techniques  of  Computer  Perfomance 
Analysis;  Computer  5,5  (September/October  1972)  pp. 39-47. 

Though  many  of  the  entries  in  this  bibliography  are  system- 
oriented,  there  are  still  more  which  can  provide  ideas  for 
structuring  programs  in  an  attempt  to  improve  their  operating 
efficiency. 


MILLE574 

Miller,  L.A. ;  Programming  by  Non-Programmers;  International 
Journal  of  Man-Machine  Studies  6,2  (March  1974)  pp. 237-260. 

This  article  is  a  study  on  the  result  of  one  attempt  to  extend  the 
understanding  of  the  behavioural  processes  and  problems  involved 
in  programming.  Twelve  non-programmers  solved  six  problems 
similar  in  nature  but  different  in  tests  (affirmation  vs. 
negation)  and  relations  (conjunction  vs.  disjunction) . 

The  results  confirmed  earlier  results  that  negation  and 
disjunction  were  more  difficult  concepts  to  program  correctly. 
Certain  control  structures  were  identified  as  being  easier  to  use, 
and  it  was  noted  that  debugging  took  an  inordinate  amount  of  time 
with  respect  to  the  initial  programming.  The  conclusions  bear  out 
what  some  people  already  feel  to  be  intuitively  obvious.  In 
particular,  the  structure  of  the  program  is  found  to  be  important 
to  its  efficiency  and  correctness. 


MILLS71 

Mills,  H.D.;  Chief  Programmer  Teams:  Principles  and  Procedures; 
lEM  Federal  Systems  Division,  no.  FSC71-5108  (June  1971)  pp.  1-27. 
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This  paper  describes  the  basic  functional  characteristics  of  the 
chief  programmer  team  method  of  project  management,  and  the 
principles  which  underlie  the  method.  The  objective  is  to  achieve 
a  practical  synthesis  of  several  contemporary  theories  of  good 
programming  practice.  The  concept  of  top-down  design  is  reflected 
in  the  hierarchical  structure  of  the  team.  Structured  control 
constructs  are  used  to  obtain  program  understandability  and 
verifiability.  A  form  of  "egoless  programming,"  in  the  form  of  a 
"programming  production  library,"  is  introduced  "to  move 
programming  from  private  art  to  public  practice."  Unfortunately, 
no  concrete  evidence  is  given  to  support  the  practicality  of  the 
approach. 


MIILS72 

Mills,  H.D.;  Mathematical  Foundatiors  For  Structured  Programming; 
lEM  Federal  Systems  Divisior  7EFSC  72-6012  (February  1972)  pp.1- 
62. 

The  author  attempts  to  provide  mathematical  assurance  that  a 
technical  standard  for  structured  programming  techniques  is  sound 
and  practical.  He  observes  a  psychological  side-effect  of  using 
structured  programming:  the  programmer,  having  greater  assurance 
that  his  program  will  be  correct,  is  motivated  to  a  new  level  of 
concentration,  which  in  turn  reduces  errors  even  more.  He 
describes  programs  in  the  form  of  control  graphs,  and  proves  a 
"structure  theorem":  Any  proper  program  is  equivalent  to  a  program 
whose  formula  contains  at  most  the  BLOCK,  IF-THEN-ELSE ,  and  DO- 
DNTIL,  and  additional  functions  TFUE,  FALSE,  POP,  and  predicate 
function  TCP." 

The  advantages  of  program  structure  in  program  correctness  proofs 
are  shewn,  and  the  production  of  these  programs  by  topdown 
expansion  is  discussed. 


MILLS73a 

Mills,  H. ;  The  Complexity  of  Programs;  i 
Prggram  Test  Methods ;  Prentice-Hall, 
pp. 225-236. 


Mills  begins  by  pointing  out  that,  "in 
have  not  yet  discovered  that  complexity  h 
discuss  the  role  of  structured  progr 
understanding  programs  and  proving  progra 
two  types  of  programs:  rational  and  na 
knowledge  available  about  the  internal  me 
rational  program  is  one  whose  internal  me 
some  people;  a  natural  program  is  one  who 
known  to  no  one.  Programs  begin  in 
eventually  pass  on  to  the  natural  state 
obsolete.  His  objective  in  measuring  a 
is  to  keep  a  program  rational  for  as 
certainly  much  longer  than  at  present, 
sets  in. 
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MILLS73b 

Mills,  H.D.;  Cn  the  Develcpnient  of  Large  Reliable  Programs; 
Symposium  on  Computer  Software  Reliability,  New  York  (April 
pp. 155-159. 


In  this  paper  Mills  describes  operational  procedures  intends 
the  development  of  large  reliable  programs.  These  procedures 
based  on  top  down  structured  programming  to  provide 
structured  program  segments  which  facilitate  reading  of  pr 
text  and  testing.  Kith  respect  to  overall  program  correctness 
approach  taken  is  that  rather  than  have  to  claim  that  the 
error  has  been  found  (if  that  is  possible)  one  should  stri 
never  find  the  first  error.  Mills  feels  this  can  be  accompl 
by  restructuring  programming  from  a  private  art  into  a  p 
practice  by  having  programs  read  by  others.  Finally,  the 
introduces  the  concept  of  program  development  accounting 
means  to  record  the  process  of  program  development  and  inspec 
and  to  provide  proof  of  the  successfulness  of  the  concept  of 
finding  a  first  error  in  the  program. 
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MCFRIS71 

Morris,  D.;  The  Nature  and  Benefits  of  Modular  Operating  Systems; 
in  Hugo,  J.S.  (ed)  ,  The  Fourth  Generation .  Infotech,  Ltd., 
Berkshire,  England  (1971)  pp. 279-298. 


MCBEIS73a 

Morris,  F.I.;  Advice  on  Structuring  Compilers  and  Proving  Them 
Correct;  ACM  Symposium  on  Principles  of  Programming  Languages 
(Cotcber  1973)  pp.  144-152. 

The  author  directs  his  attention  to  proving  compiler  correctness. 
His  approach  is  algebraic,  and  entails  defining  the  source 
language,  target  language  and  their  respective  meanings  as 
heterogeneous  algebras,  then  defining  homomorphisms  (one  of  which 
represents  the  compiler)  between  these  algebras.  The  paper  deals 
mostly  with  an  example  of  the  development  and  proof  of  a  small 
compiler.  Although  this  method  proves  to  be  very  powerful,  it 
requires  considerable  background  knowledge  before  it  becomes 
understandable.  This  is  not  an  introductory  paper  by  any 
standards,  but  if  one  is  prepared  to  work  through  it  carefully,  it 
proves  to  be  extremely  worthwhile. 


MCBP.IS73b 

Morris,  J.E.;  Programming  by  Semantic  Refinement;  SIGPLAN  No 
8,9  (September  1973)  pp. 120-122. 

Programmers  are  incapable  of  efficiently  producing  rel 
programs  when  they  are  initially  confronted  with  the  detail  o 
final  program.  Semantic  refinement  is  offered  as  a  grad 
approach  from  an  abstract  design  to  a  final  implementation, 
is  achieved  by  coding  and  debugging  the  system  in  a  series  of 
precise  languages,  the  last  of  which  is  a  systems  implement 
language . 
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MCERIS73C 

Morris,  J.H.;  Protection  in  Programming  Languages;  CACM  16,1 
(January  1S73)  pp. 15-21. 

Morris  discusses  a  series  of  methods  of  protection  from  hostile 
programs.  It  is  noted  that  a  hostile  program  can  be  either  from  a 
competing  business  or  agency,  or  it  can  just  as  easily  be  your  own 
program  which  contains  bugs.  Included  in  the  list  of  devices  are 
discussions  about  procedures  as  objects,  local  objects,  type 
protection,  memory  protection,  seals,  and  trademarks.  For  memory 
protection,  one  may  make  reference  to  the  object  local  to  a 
procedure  B.  In  order  to  provide  outside  access,  the  programmer 
can  provide  reference  to  procedures  within  E.  Seals  are  a  method 
of  ensuring  that  a  programmer  has  taken  the  correct  steps  prior  to 
accessing  a  function,  and  aids  in  localization  of  accesses. 


MCBRIS73d 

Morris,  J.H.;  Types  are  not  Sets;  ACM  Symposium  on  Principles  of 
Programming  Languages  (October  1973)  pp. 120-124. 

The  author  argues  that  objects  of  a  type  should  be  should  be 
managed  (i.e.,  created  and  operated  on)  by  the  owner  of  that 
object.  He  proposes  a  module  block,  which  can  selectively  provide 
local  symbols  to  its  users,  including  the  names  of  types.  A 
module  has  sole  write  access  to  values  of  its  local  types,  but  may 
give  cut  read  access  to  such  values  if  it  chooses.  Proof  rules 
are  discussed  for  verifying  correct  use  of  modules.  Finally,  the 
author  relates  Simula  classes  and  polymorphic  functions  to  his 
modules. 


MCSEDALE73 

Mosedale,  T.W.;  PEDANT:  A  Computerized  Support  to  Program 
Modularity  Under  Limited  Memory  Conditions;  Software  -  Practice 
and  Experience  3,2  (April-June  1973)  pp. 121-143. 

The  author  notes  that  the  "building  block  approach"  is  already 
used  in  hardware,  and  suggests  its  extension  to  software.  He 
points  out  that  modularity  does  not  always  eliminate  the 
driver/buffer  program,  tut  requires  a  skillfully  created 
interface.  PEDANT  is  designed  to  work  with  large  modules,  to 
simplify  applications  where  memory  size  is  small.  Data  areas  are 
considered  to  be  undefined  until  referenced,  and  thus  outside  the 
module  blocks.  PEDANT,  acting  as  an  interpreter,  handles  all 
requests  for  data,  and  for  communication  with  other  modules. 
PEDANT  is  basically  a  link  and  load  software  system.  Modules  can 
ignore  the  source  of  data  (i.e.,  in-core,  disk,  tape)  and  can 
treat  data  as  a  resource. 


MYEBS73 

Myers,  G.J.;  Characteristics  of  Composite  Design;  Datamation  19,9 
(September  1973)  pp.  100-102. 


-54- 


Current  /^.rticles 


An  essentially  unsatisfying  discussion  cf  design  criteria  for 
highly  modular  programs.  Suggests  that  the  goal  is  a  program 
composed  of  "strong"  (closely-coupled  internally)  modules,  each 
with  a  well-defined  function  and  predictable  results,  linked  by  as 
few  arguments  as  possible.  No  real  life  example  of  such  design,  or 
its  supposed  advantages  (quickly  written,  easily  debugged,  easily 
changed)  is  provided. 

Program  structure  follows  social  structure  (Turski70) .  The  two 
key  statements  in  the  paper  are:  "Because  of  the  high 
independence  within  the  program,  interactions  and  dependencies 
among  programmers  are  reduced,"  "Programmer  assignments  can  be 
easily  shifted  to  smooth  out  the  peaks  and  valleys  on  resource 
requirements. " 


N?.SSI73 

Nassi,  I.,  and  Schneider ma n,  E;  Flowchart  Techniques  for 
Structured  Programming;  SIGPLAN  Notices  8,  8  (August  1973)  pp.12- 
27. 

With  the  acceptance  of  structured,  top-down,  gotoless  programming, 
a  computational  model  is  needed  which  prevents  unrestricted 
transfers  of  control  and  reflects  the  control  structure  of  the 
languages  suitable  for  structured  programming.  Some  advantages  of 
the  flowcharting  language  presented  are  that  the  scope  of 
iterations  and  IF-THEN-ELSE  clauses  are  well  defined  and  visible, 
that  the  scope  of  variables  is  obvious,  and  that  arbitrary 
transfers  cf  control  are  impossible. 


NA0R72 

Naur,  P. ;  An  Experiment  in  Program  Development; 
pp. 347-365. 


CR25,21 3 
EIT  12,3  (1972) 


This  paper  contains  a  detailed,  step  by  step  accou 
considerations  leading  to  a  program  for  solving  the 
Problem."  In  the  author's  opinion  at  least  some 
development  does  not,  and  can  hardly  be  made  to,  proceed 
down  process  as  advocated  by  Dijkstra  and  wirth, 
problem  solving  type  of  process  is  taking  place  in  solv 
problems.  In  this  process  high  level  program  description 
but  only  after  important  details  have  been  explored  at 
level . 
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NEELY73 

Neely,  P.M.;  Cn  Program  Control  Structure; 
Conference  (1973)  pp. 119-125. 


CR27,210 
Proceedings  of  the  ACM 


This  paper  is  primarily  concerned  with  the  improvement  of  the 
syntactic  format  cf  DO-WHILE  loops.  The  improvements  take  two 
forms,  first  a  standard  set  of  indentation  rules  to  make  reading 
the  code  easier,  and  second  the  semantics  of  the  logical  control 
of  iteration  are  separated  from  the  semantics  of  the  body  of  the 
loop. 
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Unfortunately  the  paper  has  imbedded  in  it  examples  in  FOfiTEAN. 
However  several  new  statement  types  are  suggested  including 
variants  of  the  DO-WHILE  loop  and  also  a  POSIT-Q UIT- ADMIT 
statement  which  would  be  of  particular  value  in  error  handling 
within  loop  bodies.  The  author  claims  that  by  using  his  suggested 
indentation  rules  and  syntax  one  can  insert  comments  into  any 
programming  language  code  so  that  the  code  is  described  in  terms 
of  a  particular  fixed  set  of  statement  types.  The  statement  types 
need  not  be  iirplemented  in  the  given  language,  but  the  comments 
would  emulate  the  syntax.  Thus,  the  theory  is,  a  programmer  would 
be  able  to  read  code  in  any  language  even  though  he  might  not  know 
the  particular  language  syntax. 


NEMETH71  CR22,645 
Nemeth,  A.G.,  and  Bovner,  P.D.;  User  Program  Measurement  in  a 
Time-Shared  Environment;  CACM  14,10  (October  1971)  pp. 661-666. 

The  article  presents  a  method  used  on  the  TX-2  computer  at  the  MIT 
Lincoln  Laboratory  for  the  measurement  of  time  usage  distribution, 
number  of  supervisor  program  requests,  size  of  request  blocks  and 
frequency  counts  of  user-specified  events.  It  is  a  combined 
software  and  hardware  system  that  allows  interactive  measurement 
of  pregram  performance  under  user  control.  The  events  to  be 
measured,  the  frequency  of  sampling  these  events,  the  distribution 
ccntrclling  any  random  variation  in  sampling  frequency,  the 
segment  of  the  program  to  be  measured  and  the  format  of  the  output 
are  all  user-ccntrclled  in  this  system,  which  has  been  used  to 
debug  large  programs  found  to  have  time  inefficiencies  not 
susceptible  to  logical  identification. 


OGEIN73 

Ogdin,  J.L.;  Improving  Software  Reliability;  Datamation  19,1 
(January  1973)  pp. 49-52. 

This  paper  tries  to  develop  ways  for  improving  software 
reliability,  using  modular  programming.  The  author  first  makes  a 
general  comparison  of  a  program  to  a  mathematical  function, 
showing  the  many  similarities  that  exist,  and  then  narrows  this 
cemparisen  to  tasks  and  modules. 

In  an  effort  to  provide  for  mere  reliable  software,  the  author 
discusses  several  relevant  areas,  such  as  where  the  decisions 
should  be  made  in  hierarchies  of  tasks  and  the  problem  of  changing 
specifications  for  written  modules.  When  the  modules  are 
redefined,  they  should  be  renamed.  Finally,  program  bugs  are 
classified  and  then  reasons  and  solutions  are  given  for  them. 


CFGANICK72 
Organick, 
Structure ; 


CE24, 104 

E . I . ;  The  Mu It ic s  System :  An  Examination  of  its 

MIT  Press,  Cambridge,  Massachusetts  (1972)  pp.  1-392. 
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PARNAS71 

Parnas,  D.I.;  A  Paradigm  for  Software  Module  Specification  with 
Examples;  Carnegie-Mellon  University,  Department  of  Computer 
Science  (March  1971)  pp.1-19. 


PAENAS72a 

Parnas,  D.I.;  A  Course  on  Software  Engineering  Techniques;  SIGCSE 
Bulletin  ^4,1  (March  1972)  pp.  154-159. 


PAENAS72b  CE23,949 
Parnas,  D.L.;  A  Technique  for  Software  Module  Specifications  with 
Examples;  CACM  15,5  (May  1972)  pp. 330-336. 


An  approach  to  writing  software  specifications  for  parts  of 
systems  is  presented.  This  is  an  example  of  Dijkstra's  principle 
of  non-interference.  The  technique  attempts  to  provide 
specifications  with  sufficient  information  to  allow  interaction  of 
the  parts  only  as  a  whole.  Parnas  suggests  a  structure  where 
specifications  could  be  tested  for  completeness  and  correctness 
before  detailed  coding.  Although  the  idea  is  at  a  young  stage  his 
analysis  to  this  pcint  is  useful  and  worth  noting. 


PAENAS72C 

Parnas,  D.I.;  Cn  the  Criteria 
Modules;  CACM  15,12  (December 
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CR25,197 

Used  in  Decomposing  Systems  into 
1972)  pp. 1053-1058. 

Modularization  involves  decomposition  of  the  problem  into  modules 
corresponding  to  each  major  step  in  the  processing.  Parnas  shows 
by  example  that  modifying  the  data  structure  specifications  (i.e., 
storage  media,  packing  of  information,  input  format)  would  require 
an  extensive  rewriting  of  most  modules.  He  suggests  that  for 
systems  greater  than  5,000-10,000  instructions,  the  criterion  of 
•information  hiding*  be  used  to  guide  decomposition.  Every  module 
is  characterized  by  a  design  decision  it  hides  from  all  other 
modules.  Although  efficient  implementation  may  involve  a 
reshuffling  of  the  module  code  tc  produce  the  final  system, 
maintaining  both  levels  of  code  wculd  combat  this  objection. 


PAENAS72d  CE25,506 

Parnas,  D.L.;  Some  Conclusions  frcm  an  Experiment  in  Software 
Engineering  Techniques;  Proceedings  of  the  FJCC  41  (1972)  pp.325- 

329. 
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students  were  generally  poor  programmers,  some  modules  were  not 
finished,  the  language  used  was  W^-TFIV,  etc.  The  final  integration 
and  testing  of  modules  was  done  by  someone  with  "absolute  no 
knowledge  cf  the  structure  of  any  module. " 


p;^.EN;^.S72e  CB25,351 
Parnas,  D.L.;  Information  Distribution  i^.spects  of  Design 
Methodology;  Proceedings  of  IFIP  Congress  71  (1972)  pp. 339-344. 

The  thesis  of  this  paper  is  that  a  designer  may  retain  tighter 
control  on  the  structure  of  his  system  if  he  controls  the 
distribution  of  information.  Parnas  observes  that  "a  good 
programmer  makes  use  of  the  useable  information  given  him."  The 
conseguence  is  that  a  good  programmer,  given  all  the  information 
about  the  system  design  will  always  find  some  efficiencies  in  "bit 
twiddling."  The  unfortunate  side  effect  is  that  modules  become 
highly  interconnected,  making  for  nasty  problems  later  in  the 
design.  Restriction  of  information  distribution  reduces  this 
interdependency.  Information  about  design  decisions  can  now  be 
used,  by  the  designer,  to  verify  that  the  code  produced  is 
consistent  with  design  objectives.  Several  good  examples  are 
given  which  support  the  theme  of  the  paper. 


P^BNAS72f 

Parnas  D.L.;  Response  to  Detected  Errors  in  Well-Structured 
Programs;  Carnegie-Mellon  University,  Department  of  Computer 
Science  (July  1972)  pp.1-18. 

The  author's  main  assumption  is  that  even  well-structured  programs 
will  have  run-time  errors  and  hence  reliable  systems  have  to  be 
designed  with  error  handling  and  self-diagnosis  as  a  fundamental 
consideration.  The  foremcst  problem  with  error  handling  in  a 
structured  program  is  that  the  level  of  abstraction  where  the 
error  is  detected  is  usually  lower  than  the  level  where 
irformaticn  for  proper  response  to  that  error  is  available. 

A  methodclcgy  fcr  module  design  based  on  the  concept  of  the 
software  analog  of  the  hardware  "trap"  is  presented  to  deal  with 
this  problem.  The  "software  trap"  technique  allows  error 
conditions  to  be  "reflected"  up  througli  levels  of  abtraction  while 
maintaining  a  structured  discipline. 

A  detailed  example  of  such  a  design  is  given  along  with 
suggestions  of  what  type  of  applications  would  benefit  from  the 
discussed  methods. 


PEA.BSCN73 

Pearson,  K.M.;  Cataloguing  Computer  Software;  Eatamaticn  19,10 
(October  1973)  pp. 87-91. 

This  article  discusses  the  present  methods  of  cataloguing  systems 
software,  and  argues  that  it  is  inadequate.  Instead,  the  author 
espouses  his  own  system,  involving  complete  description  and 
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PETERSCN73 

Peterson,  W.W.,  Kasami,  T.,  Tokura,  N. ; 
While,  Repeat,  and  Exit  Statements; 
pp , 503-51 2 . 


CE26, 120 

On  the  Capabilities  of 
CACM  16,8  (i^.ugust  1973) 
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PCCLE73  CR26,539 

Pccle,  P.C.;  Debugging  and  Testing;  in  Bauer,  F.L.(ed.),  Advanced 
Course  on  Software  Engineering;  S pringer- Ver lag ,  New  York  (1973) 
pp. 278-31 6. 

The  author  points  out  that  since  every  program  written  will  have 
errors,  it  is  most  important  that  programmers  write  their  programs 
allowing  for  ease  of  subsequent  testing  and  debugging  (unlike 
present  practice,  which  tends  to  assume  the  program  will  work 
without  error) .  He  suggests  planning  for  the  testing  and 
debugging  phases.  In  particular,  "debugging  code"  should  be  put 
in  right  at  the  start  --  rather  than  having  it  inserted  when  bug 
arise.  The  most  useful  form  of  debugging  code  would  be  one  whic 
would  remain  in  the  program  in  its  final  form,  but  would  not  be 
executed  unless  desired  (when,  for  example,  a  new  bug  appears). 
The  use  of  debugging  code,  a  modular  program  structure,  and 
parameterization  of  important  variables  would  make  testing  and 
debugging  much  easier.  A  discussion  is  given  of  classical 
debugging  techniques  —  most  of  which  have  the  pr  oblem  of 
generating  too  much  output  in  an  awkward  form  for  analysis.  On¬ 
line  debugging  seems  popular,  but  has  problems  (principally,  how 
to  manipulate  compiled  code)  .  New  debugging  and  testing  aids 
should  also  take  into  account  the  fact  that  corrections  to  present 
programs  are  often  not  fully  tested  or  documented  because  the 
debugging  and  testing  methods  are  awkward  and  time  consuming. 


PBOKOF73  CR25,529 
Prokop,  J.S.;  Cn  Proving  the  Correctness  of  Computer  Programs;  in 
Hetzel,  W.C.  (ed.);  Program  Test  Methods:  Prentice-Hall,  Englewood 
Cliffs  (1973)  pp. 29-37. 
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Various  ways  of  proving  program  correctness,  both  formal  and 
informal,  are  examined.  When  all  the  complex  factors  which  act  or. 
a  program  during  the  four  stages  of  analysis,  coding,  compilation 
and  object  are  considered  it  is  concluded  (not  too  surprisingly) 
that  current  proof  technigues  are  impractical  on  anything  but 
fairly  trivial  problems.  It  is  concluded  that  "we  are  not  very 
much  advanced  in  the  art  or  science  of  proving  computer  programs 
tc  be  correct."  k  plea  is  made  for  the  "transference  of  proof 
techniques  into  a  production  environment  for  computer  programs 
which  are  somewhere  in  the  middle  of  the  continuum  from  trivial  to 
impossible, " 


F-AIN73  CE25,20U 
Fain,  M. ;  Two  Unusual  Methods  for  Debugging  System  Software; 
Software  -  Practice  and  Experience  3,1  ( January-March  1973) 
pp.6 1-63. 

In  the  first  part  of  the  paper,  the  author  suggests  an  automated 
approach  tc  bug-finding.  A  program  should  be  written,  capable  of 
accepting  a  correct  source-language  program,  and  randomizing  the 
program  according  to  an  adjustable  randomization  factor.  In  the 
s<=cond  part,  "bug  contests"  are  suggested,  wherin  users  might  be 
encouraged  tc  throughly  test  new  software,  and  at  the  same  time 
expand  their  knowledge  of  the  capabilities  of  the  software,  by 
offering  cash  rewards  for  each  previously  undetected  bug  or  quirk. 


FA.MAMCCFTPY75 

Famamocrthy,  C.V.,  Ho,  S.-E.,F.;  Testing  Large  Software  with 
Automated  Software  Evaluation  Systems;  IEEE  Transactions  on 
Software  Engineering  SE-1,1  (March  1975)  pp. 46-58. 

This  paper  points  out  that  the  ma  jo  r  expense  in  computer  sy  stem s 
at  present  and  in  the  future  is  software.  Since  proving  large- 
scale  software  systems  correct  by  formal  proof  is  currently 
infeasible,  the  authors  present  automated  software  tools  as 
valuable  instruments  for  improving  software  reliability  and 
reducing  the  high  cost  of  software  systems. 

The  paper  begins  by  discussing  the  two  basic  requirements  for  all 
software  systems  (correctness  and  performance)  and  the  problems 
involved  in  achieving  these  requirements.  The  classifications  of 
automated  tools  are  given  and  the  main  features  and  functions  of 
these  tools  are  described.  An  example  of  the  application  of  a 
linear  programming  technique  to  the  selection  of  an  optimal  set  of 
automated  tools  for  implementation  in  a  software  evaluation  system 
IS  given.  The  performances  of  three  actual  automated  software 
evaluation  systems  FACES,  ACE.S  ,  and  PACE  -  are  discussed.  The 
authors  conclude  that  partial  validation  with  the  aid  of  software 
evaluation  sy ste ms  appears  to  be  the  most  cost  effective  approach 
tc  improving  the  reliability  of  large  software  systems. 

This  article  can  serve  as  an  introduction  to  the  area  of  automated 
soft  ware  evaluation.  Terminology  and  concepts  associated  with 
this  area  are  explained,  and  it  would  be  of  interest  tc  those  with 
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little  background  in  this  field, 
the  chief  interest  would  be 
inf ormaticn . 


For  those  more  knowledgeable, 
the  references  to  more  in-depth 


E^^NDELLTI 

Bandell,  E.;  Highly 
Newcastle  upon  Tyne, 


Reliable  Computing  Systems;  University 
Technical  Report  20  (1971)  pp.1-39. 


of 


This  report  discusses  the  needs  for  and  the  problems  of  achieving 
high  reliability  from  complex  computing  systems.  System 
performance  and  system  reliability  are  both  commodities  for  which 
the  user  has  to  pay.  Usually,  they  are  inversely  related  (e.g., 
high  system  reliability  usually  means  a  loss  in  system 
performance) .  Operating  systems  are  intended  to  extend  the 
reliability  of  and  cope  with  the  unreliability  of  the  hardware. 
However,  it  may  turn  out  that  the  operating  system  presents  a 
bigger  reliability  problem  than  the  hardware.  In  a  computing 
system,  it  should  be  the  responsibility  of  the  hardware  to  detect 
hardware  errors  and  the  responsibility  of  the  operating  system  to 
cope  with  and  isolate  these  errors. 


The  user  should  have  a  measure  of  the  reliability  of  his  system. 
The  correctness  of  software,  and  thus  its  reliability,  is  relative 
to  some  criteria.  These  criteria  should  be  part  of  the  detailed 
specifications  and  design  of  the  system.  Nevertheless,  computing 
systems  should  have  previsions  for  coping  with  software  bugs, 
similar  tc  hardware  error  handling  facilities,  since  the  absence 
of  bugs  cannot  be  guaranteed.  Thus,  a  reliable  system  should  have 
effective  means  for  coping  with  and  isolating  both  hardware  and 
software  errors  and  should  be  capable  of  continuing,  if  possible, 
even  though  errors  have  occurred. 


I n  conclusion  Randell 
undertaken  in  designing  a 
and  complex  environment 
extent  to  which  reliance 
functioning  of  the  system 


states  that  "the  most  vital  task  to  be 
computing  system  for  a  highly  critical 
is  that  of  attempting  to  minimize  the 
is  put  on  the  correct  and  continuing 

If 


R;^.NDEI172 
Randell,  E.; 
Reliability ; 


CE25, 107 

Operating  Systems;  The  Problems  of  Performance  and 
Proceedings  of  IFIP  Congress  71  (1972)  pp. 281-290. 


RICHARES71 

Richards,  K. ;  The  Portability  of  the  ECPL  Compiler;  Software 
Practice  and  Experience  1,2  (^^pril/June  1971)  pp.  135-146. 


RIEDLE72 

R iddle ,  W  .  E . ;  An 
Stanford  linear 
(September  1972) 


Annotated  Bibliography  on  Software 
Accelerator  Center,  Computation 
pp. 1-103. 


Architecture ; 
Group,  no.  138 
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RDSTIN71  CE22,801 

Eustin,  E.  (ed.);  Debugging  Technigues  in  Large  Systems:  Erentice- 
Hall,  N.J.  (1971)  pp. 1-141. 

This  book  is  concerned  with  the  "ccntroi  and  extermination”  of 
"bugs"  in  highly  complex  programming  systems.  Some  topics  covered 
are:  procedures  to  guarantee  programs  to  be  free  of  bugs,  style 

that  avoids  or  isolates  bugs,  strongly  disciplined  testing 
techniques,  and  specific  methcds  fcr  particular  environments.  The 
fcllcwing  papers  are  included: 

Elair,  J.;  Extendable  Non-Interactive  Debugging 
Grishman,  E. ;  Criteria  for  a  Debugging  Language 
King,  J.  ;  P.  Verifying  Compiler 

Kulsrud,  H.E.;  Extending  the  Interactive  Debugging  System 
Helper 

Mills,  H. ;  Top  Down  Programming  in  Large  Systems 
Schwartz,  J. ;  An  Overview  of  Eugs 
Supnik,  E.M.;  Debugging  Under  Simulation 


SAMMET71 

Sammet,  J.E.;  A  Brief  Survey  of  Languages  Used  in  Systems 
Implementation;  SIGFLAN  Notices  6,9  (October  1971)  pp.1-19. 

A  gocd,  concise  survey  which  touches  upon  the  following  topics: 
managerial  and  technical  reasons  for  deciding  tc  program  in  a 
high-level  language;  some  of  the  cbvious  drawbacks  to  high-level 
languages;  a  list  of  "motherhood"  criteria  for  desirable 
programming  language  characteristics;  brief  and  nct-too-usef ul 
descriptions  of:  ALGOL,  BLISS,  FOETEAN,  IMP,  LELTEAN,  NELIAC, 
Pascal,  and  PL/I.  Recommended,  and  it's  short. 


SATTEETHWAITE72  CE2 

Satte rth wai te ,  E. ;  Debugging  Teels  for  High-Level  Langu 
Software  -  Practice  and  Experience  2,3  (July-Septeraber 
pp. 197-21 7. 

This  article  stresses  the  need  for  reviving  the  dialogue  be 
man  and  machine,  which  was  lost  in  the  transition  to  higher- 
languages.  As  an  example  of  a  modest  but  significant  step  t 
such  a  revival,  the  author  describes  a  programming  system 
Algol  W  "which  supports  a  range  of  debugging  tools  and  techni 
all  based  entirely  upon  the  high  level  language  used  by 
programmer."  Four  design  criteria  were  specified: 

1)  All  informaticn  to  the  user  should  be  expressed  in  ter 
his  program  and  Algol  W. 

2)  The  compiler  should  produce  machine  code,  which  should  n 
significan  degraded  by  debugging  requirements,  and  which  s 
execute  at  full  hardware  speed  when  net  in  debugging  mode. 

3)  Resource  requirements,  especially  I/O,  should  be  mod 
enough  for  use  by  students  with  limited  budgets. 
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4)  Debugging  tools  should  be  easy  to  invoke,  and  default 
information  should  encourage  programmers  to  critically  re-examine 
their  programs,  as  well  as  help  programmers  in  diagnosing  program 
failure , 

Discussed  were  system  organization  and  aspects  of  the  /360 
i nplementation  of  the  debugging  system.  Performance  of  this 
implementation  was  evaluated  fcr  Algol  W  programs  chosen  from  a 
variety  of  diverse  applications. 

The  system  is  not  the  programmer's  answer  to  debugging,  but  it  has 
gene  a  significant  way  in  providing  an  example  of  useful,  easy-to- 
invoke  feedback  tc  those  programming  in  high-level  languages. 


SCHNEIDEEMAN73 
Schneiderman,  E., 
State  University 
Computer  Science, 


and  Scheuerman,  P.; 

of  New  York  at 
Technical  Peport  16 


Structured  Data  Structures 
Stony  Erook,  Department  o 
(June  1973)  pp.1-34. 


The  report  proposes  a  Data  Structure  Description  and  Manipulation 
Language  (ESDMl)  which  provides  fcr  the  creation  of  a  restricted 
class  of  data  structures,  but  ensures  the  correctness  of  the 
program.  This  is  accomplished  by  having  the  user  explicitly 
declare  the  form  of  the  structure  (e.g.,  list,  tree,  ring,  queue, 
stack  and  deque) ,  restrict  the  permissible  operations  on  the 
structure,  and  specify  execution  time  checks  to  ensure  the  form  of 
the  structure  is  not  altered  (e.g.,  by  the  insertion  of  some 
pointer) .  The  authors  claim  that  they  wish  tc  eliminate 
unrestricted  tranches  or  edges  (i.e.,  pointers)  from  data 
structures  just  as  the  goto  has  been  eliminated  to  avoid  poorly 
structured  programs.  They  also  claim  that  using  their  system  top- 
down  programming  can  be  achieved  in  terms  of  data  structures  by 
having  the  nodes  of  a  given  level  structure  serve  as  headers  for 
the  structures  at  the  next  level. 


SCCWEN71 

Scowen,  E.S.,  Allin,  D.,  Hillman,  A.D.,  and  Shimell,  M.;  SOAP  -  A 
Program  which  Documents  and  Edits  ALGOL60  Programs;  Computer 
Journal  14,2  (1971)  pp. 133-135. 

This  paper  discusses  SOAP,  a  paragrapher  for  ALGOL60  programs. 
The  program  is  a  sort  of  parser,  doing  some  syntax  checking.  The 
program  allows  the  option  of  replacing  any  token  terminal  wherever 
it  occurs  with  another  terminal.  The  documentation  referred  to, 
however,  is  only  a  cross-reference  listing,  with  some  nice 
features.  The  paragrapher,  then,  does  not  really  do  any 
documentation,  but  merely  produces  bookkeeping  listings. 


SHAW72 

Shaw,  A.W.  and  Weiderman, 
Education  and  Eesearch; 
pp. 1505-15C9. 


CE25,285 

N.H.;  A  Multiprogramming  System  for 
Proceedings  of  IFIP  Congress  71  (1972) 
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SIME73 

Sime,  M.E.,  Green,  T.E.G.,  and 
Evaluation  of  Two  Conditional 
Languages;  International  Journal 
(January  1973)  pp. 105-115. 


Guest,  E. J. ; 
Constructs  Used 
of  Man-Machine 


CR25,309 
Psychological 
in  Computer 
Studies  5,1 


Although  papers  comparing  structured  and  unstructured 
exist,  very  little  hard  data  has  been  presented.  Most 
talk  about  users  with  some  experience.  Ey  adoptin 
simplified  language,  and  through  the  use  of  interactive 
the  authors  have  obtained  data  comparing  IF... GO  TO  to  a 
structure  using  non-experienced  users.  The  results  ve 
current  critisism  of  the  GOTO,  but  more  important  an  new 
studying  features  of  languages  is  presented. 
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SIMMONS72 

Simmons,  E.E.;  The  Art  of  Writing  Large  Programs;  Computer  5,2 
(March/April  1972)  pp. 43-49. 

This  article  is  oriented  towards  alleviating  problems  one 
encounters  when  writing  large  programs  and  improving  programmer 
productivity.  First,  many  factors  such  as  poor  communications  and 
programmer  turnover  are  discussed  as  prctlem  areas  in  writing 
large  programs.  Then  techniques  for  improving  programmer 
productivity  are  discussed,  with  emphasis  on  improving 
communications  between  programmers  and  managers,  users,  and  the 
general  environment.  The  areas  dealt  with  are  programmer  task 
assignment  and  supervision,  programmer  environment,  programming 
techniques,  and  program  documentation.  Although  a  brief  treatment 
of  all  these  topics  is  given,  the  author  seems  to  touch  on  most 
major  areas  of  concern  and  offers  practical  advice  as  to  how  to 
write  large  programs. 


SMITH72a 

Smith,  D.;  An  Organization  for  Successful  Project 
Proceedings  of  the  SJCC  40  (May  1972)  pp. 129-140. 


CF.2  3,741 
Manage  ment ; 


Describes  some  of  the  major 
including  those  associated  with 
delays  and  excessive  costs, 
management  design  which  present 
general  project  management,  b 
much  on  intuitive  ideas. 


problems  in  software  development 
unsatisfactory  products,  schedule 
Gives  a  good  top-down  project 
s  most  of  the  major  ideas  in 
ut  is  overly  general  depending  too 


SMITH72b  CR24,582 
Smith,  J.M.;  Proof  and  Validation  of  Program  Correctness;  The 
Computer  Journal  15,2  (May  1972)  pp. 130-131. 

The  author  points  out  that  ever  since  1962  when  McCarthy  raised 
the  concept  that  programs  should  be  proved  correct  rather  than 
merely  verified,  considerable  effort  has  been  devoted  to  the  study 
of  techniques  for  producing  such  proofs.  So  far  little  progress 
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has  been  made  although  this 
programming  languages,  theory  of 


effort  has  lead  to  advances  in 
algorithms,  and  system  theory. 


The  author  proposes  that  it  may  not  be 
correctness  of  practical  programs  rigorously 
definition  of  program  correctness  as  stated 
basis  of  this  definition  is  the  concept  of  a 
•desired  result'.  In  general  it  is  not  always  possible  to  define 
this  desired  result  and  the  author  proposes  other  approaches  to 
program  validation  by  which  program  errors  can  be  reduced  and  the 
confidence  level  of  a  program  increased. 


possible  to  prove  the 
enough  to  satisfy  the 
by  Manna  in  1969,  The 
program  yielding  the 


SN0WDCN72 

Snowdon,  E.P..  ;  PEARL:  An  Interactive  System  for  the  Preparation 
and  Validation  of  Structured  Programs;  SIGPLAN  Notices  7,3  (March 
1972)  pp.9-26. 


The  author  describes  a  partially  implemented  inter 
whose  purpose  is  to  assist  the  programmer  in  writin 
programs.  Provisions  exist  in  PEARL  for  some  assis 
program  correctness.  The  system  restricts  its  attenti 
sequential  programs  designed  by  a  single  programmer. 


active  system 
g  structured 
tance  towards 
on  to  small. 


Initially,  an  ideal  ’’machine"  is  describe 
specification  of  its  data  types  and  operations,  a 
written  for  that  machine.  The  introduction  of 
(and  programs  for  them)  serves  to  refine  the  mean 
introduced  programs  and  constructs.  Condition 
operations  in  order  to  aid  in  ensuring  program  co 
particular  machine. 
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The  system  has  various  facilities  for  program 
incompletely  specified  programs  can  be  run,  as  well 
with  PEARL  requesting  assistance  upon  encountering 
which  has  not  yet  been  fully  explained. 
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SPC0NER71  CR22,297 

Spooner  C.R.;  A  Software  Architecture  for  the  70*s;  Software 
Practice  and  Experience  (1971)  pp.5-37. 

The  author  describes  a  framework  for  general  purpose  systems  which 
he  claims  will  be  applicable  through  the  1970s.  He  describes 
Dijkstra's  "onion-ring"  approach  to  minimize  the  scope  of  effect 
(or  the  prcpogation)  of  software  errors.  He  proceeds  to  discuss 
the  use  of  a  "kernel"  of  code  as  the  enforcing  mechanism  of 
modularity.  No  module  is  to  receive  more  privileges  than  it 
requires,  thus  limiting  the  scope  of  any  faults.  Desirable 
features  of  future  hardware  implementations  are  listed. 

STANDISH75 

Standish,  T.A. ;  Extensibility  in  Programming  Language  Design; 
SIGPLAN  Notices  10,7  (July  1975)  pp. 18-21. 
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A  summary  of  the  aspirations  of  the  extensible  language  movement 
and  its  progress  to  date  is  presented.  This  paper  discusses  a 
variety  of  extension  techniques  that  have  teen  developed,  and  what 
has  teen  learned  about  extensibility  from  attempted 
implementations.  He  suggests  a  basic  difficulty  with  extensible 
languages  is  the  effort  required  to  utilize  them  to  their  full 
capacity.  A  well-written  and  informative  article. 


STEVENS74 

Stevens,  W.P.,  Myers,  G.T.,  Constantine,  L.L.;  Structured  Design; 
lEM  Systems  Journal  13,2  (1974)  pp. 115-139. 


The  authors  provide  the  suggest 
programming  be  carried  further,  i 
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considerable  time  is  spent  in  the 
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search  of  An  Identity;  Datamation  18,3  (March  1972) 


acks  the 

programmers  in  society,  A 
as  well  as  academia  is 
question  of  programmer  certification 


problem  of  the  professional  status  of 
broad  range  of  opinions  from  industry 
presented  in  an  unbiased  manner.  The 
is  examined  both  from  a 


philosophioal  and  a  practical  viewpoint. 
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Structure;  in  Hugo,  J.S.,  The  Fourth  Generation,  Infotech,  Ltd., 
Berkshire,  England  (1971)  pp. 341-356. 


Ti^LI/^.FEEROTI 

Taliaferro,  W. M. ;  Modularity.  The  Key 
Software  -  Practice  and  Experience 
pp. 245-257. 


to  System  Growth  Potential; 
1,3  (July-September  1971) 


TCn71 

Tcu,  J.T.  (ed.);  Software  Engineering,  Volumes  1  and  2;  Academic 
Press  (1971) . 

A  collection  of  papers  presented  at  a  symposium  in  1969.  The 
first  volume  covers  computer  organization,  systems  programming, 
and  programming  languages;  the  second  volume  covers  information 
retrieval,  pattern  processing,  and  computer  networks.  The 
following  papers  are  included: 

Barton,  E.S.;  Ideas  for  Computer  Systems  Organization:  A 
Personal  Survey 

Berner,  B.W.;  Manageable  Software  Engineering 

Maurer,  W.;  Generalized  Interpretation  and  Compilation 


TSICHEITZZS73 

Tsichritzis,  D.;  Project  Management;  in  F.L.  Bauer  (ed.).  Advanced 
Course  on  Software  Engineering;  S pringer-Verlag ,  New  York  (1973) 
pp . 374-384 . 

The  author  feels  there  are  two  main  reasons  for  difficulty  a 
managing  software  projects:  poor  management  (due  to  the  lack  of 
persons  with  both  adeguate  technical  and  managerial  skills) ;  and 
the  frequent  changes  in  job  specification  and  personnel  that 
occur.  Tsichritzis  stresses  the  need  for  good  team  communication 
and  concludes  that  small  teams  (5-10  people)  are  the  best  aid  to 
communication.  The  three  main  phases  of  a  software  project  as  the 
author  views  them  are  outlined,  including  a  brief  example  from 
project  SUE  at  Toronto.  Finally,  Tsichritzis  discusses  the 
management  of  ‘large*  projects.  Here  again  he  questions  the  need 
for  a  'large*  project  and  advocates  instead  a  small  group  of 
highly  skilled  persons. 


VAN  DUYN72 

Van  Duyn,  J. ;  Documentation  Manual;  Auerbach,  Philadelphia  (1972) 
pp . 1- 1 58 . 


This  is  a  compact  paperback  w 
processing  systems.  The  book  is 
for  each  part  of  the  documentatio 
illustrate  each  section.  The  app 
illustrated  with  forms,  charts, 
feel  it  necessary  to  justify  the 


hich  covers  documentation  of  data 
organized  as  a  set  of  templates 
n  with  one  or  two  case  studies  to 
roach  is  rigid  and  is  profusely 
and  tables.  The  author  does  not 
methods  presented,  since  they  are 
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taken  from  practices  that  are  standard  and  widely  accepted,  at 
least  in  the  commercial  programming  field. 


V;^.NDEE  NCCI71 

Vander  Noot,  T.J.;  System  Testing.. 
17,21  (November  1971). 


A  Taboo  Subject;  Datamation 


This  article  suggests  hew  the  programmer  should  test  his  program 
tc  detect  bugs  and  how  the  customer  should  test  a  received 
product. 


VCN  PESCHKE71 
ven  Peschke,  J.  ; 
Notices  6,4  (1971) 


PL/I  Subsets 
pp. 16- 22. 


fer  Software  Writing;  SIGPLAN 


the  possibility 
in  compiler  and 


The  article  discusses 
PL/I  language  for  use 
The  primary  aims  of  high  level  languages  are  machine  ind 
and  readability.  This  is  contrasted  with  the  need  of  the 


of  extending  a  subs 
operating  system 


full  control  over  all  the  featur 
solution  of  the  problem  is  not  a 
but  one  that  is  tailored  to 
same  time  retaining  some  of 


of  software  to  have 
machine.  Therefore  the 
high  level  language, 
computer,  while  at  the 
features  cf  a  high  level  language.  The  author  suggests 
of  PL/I  with  some  extensions  which  he  describes  in  the 
which  would  become  a  good  language  for  software  writing. 


et  of  the 
wri ting  . 
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es  of  the 
ge  neral 
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the  good 
a  subset 
article. 


W;^.ESWCBTH73 
Wadsworth,  M.D.;  The 
Prentice-Hall  (1973) 


Human  Side 
pp. 1-24h . 


of  Data  Processing 


CP.  2680  4 
Ma  rage  ment ; 


The  text  is  intended  for  large  computer  installations  with  a  staff 
of  15  or  more,  however,  the  arguments  are  valid  for  any 
super i or/ subordinate  relationship. 

This  book  has  ten  chapters.  Chapter  one  presents  five  levels  of 
human  needs  (psychological,  security,  social,  esteem,  and  self- 
realization  or  achievement)  and  four  styles  of  leadership 
(authoritarian,  democratic,  laissez-faire,  and  buddy-buddy) .  To 
be  effective,  the  manager  must  learn  to  use  all  four  styles  of 
leadership.  Chapters  two  through  five  certain  15  case  studies 
illustrating  which  leadership  style  is  best  suited  to  satisfy  an 
identifiable  level  of  human  need  in  order  to  improve  individual 
performance.  The  checklists  to  identify  the  level  of  human  need 
are  excellent.  Chapters  six  through  eight  give  additional 
examples  to  improve  profitability  and  productivity  in  system 
development,  system  maintenance,  and  computer  operations 
respectively.  Chapter  nine  details  ways  to  improve  "user" 
acceptance,  cooperation,  and  involvement.  Chapter  ten  is  directed 
tc  the  EDF  manager. 
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WAREEN75 

Warren,  J.C.,  Jr.;  Software  Portability:  A  Survey  of  Approaches 
and  Problems;  IZEE  CCMPCON,  Spring  1975  (February  1975)  pp.253» 
256. 

In  this  paper  the  author  outlines  the  pertinent  concepts, 
advantages  and  disadvantages  of  portable  software.  The  different 
approaches  that  have  been  used  are  presented  along  with  reference 
examples  of  each  method.  The  paper  includes  a  major  discussion  of 
portability  via  high  level  languages,  and  via  abstract  machines 
and  pseudo-codes.  The  conclusion  outlines  some  approach- 
independent  problems  and  suggests  a  number  of  areas  in  which 
research  is  needed.  The  paper  includes  a  large  list  of 
references . 


WASSFRMAN75 

Wasserman,  A. I.;  Issues  in  Programming  Language  Design  --  An 
Overview;  AFIPS  National  Conference  Proceedings  1975  pp. 297-299. 

A  summary  of  the  developments  (and  the  reasons  for  them)  in 
programming  language  design.  The  objectives  of  design  are 
discussed  and  definitions  and  descriptions  of  the  main  areas  of 
research  are  given.  Three  fundamental  questions  which  the  author 
believes  underlie  the  current  research  and  development  are  given 
as  a  conclusion.  This  is  a  very  comprehensible  article  coverin 
many  aspects  of  design,  and  could  serve  as  a  useful  consclidatio 
of  knowledge,  cr  as  a  very  good  introduction  to  the  area.  An 
extensive  list  of  references  is  provided. 


WATKINS73 

Watkins,  E.P.;  Towards  a  Theory  of  Documentation;  The  Australian 
Computer  Journal  5,2  (May  1973)  pp. 57-61. 

An  advance  is  made  toward  the  theory  of  documentation  by  the 
definition  cf  intensional  documentation,  extensional 

documentation,  and  level  of  detail.  This  provides  a  formal 
statement  cf  the  structure  of  documentation.  The  statement  not 
only  matches  the  current  intuitive  concepts,  but  gives  a  deeper 
insight  into  the  reasons  for  and  values  of  these  structures. 


WIGERFIT71  CR23,516 
Wegbreit,  E. ;  The  FCL  Programming  System;  Proceedings  of  the  FJCC 
39  (1971)  pp. 253-262. 

This  article  describes  a  number  of  ideas  for  facilitating  program 
production  which  are  being  conglomerated  into  a  project  called  the 
ECI  programming  system.  The  goals  cf  the  project  are: 

1)  To  allow  problem-oriented  description  of  data  types  and 
control  structur  and  control  ever  a  wide  range  of  application 
areas , 

2)  To  facilitate  program  construction  and  debugging. 
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3)  To  allow,  and  assist  in,  the  development  of  highly  efficient 
programs. 


4)  To  facilitate  smooth  progression  between  initial  program 
construction  an  final  realization  of  an  efficient  product. 


Ideas  being  implemented  to  accomplish 
compatible  interpreter-compiler  scheme;  a 
(extersions  allowed  on  syntax,  da 
structures) ;  systematic  variability 
bootstrapping,  allows  sophisticated  ma 
greater  user  control  over  errors  and  inte 
interactive  multiprogramming  scheme, 
favors  a  very  flexible  and  powerful  set 
production . 


these  goals  include  a 
very  extensible  language 
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WEIDEPMA.N71 

Weiderman,  N.H.;  Synchronization  and  Simulation  in  Operating 
System  Construction;  Ph.D.  Thesis,  Cornell  University,  Department 
of  Computer  Science  (September  1971). 

Description  of  an  operating  system  design  methodology  which 
proceeds  in  a  strict  top-dcwn  order  and  combines  simulation  with 
implementation  to  verify  system  structure  and  predict  object- 
system  performance.  A  good  review  of  other  techniques  is 
included;  chapters  three  and  four  are  of  particular  interest.  For 
comparison  purposes,  see  Graham's  D.E.S.,  Parnas's  SODAS  and  the 
Zurcher  and  Eandell  paper. 


WEINEERG71 
Weinberg,  G.M. 
Ncstrand  (1971) 


Ik®  Ps_ycholog_y  of  Computer 

pp. 1-268. 


CP23,001 
Programming ;  Van 


This  book  is  unique  in  that  it  discusses  the  art  and  s 
computer  programming  not  from  the  viewpoint  of  the  mach 
programs  which  are  generally  thought  of  as  its  mai 
matter,  but  from  the  human  factors  viewpoint.  The  author 
the  factors  in  a  programmer's  psychological  makeup  whi 
his  programs,  and  the  ways  in  which  programs  vary  accordi 
personality  and  emotional  outlook  of  their  creators.  Pr 
team  environments  are  looked  at  from  the  point  of  view 
individual  programmer.  The  effect  of  both  his  formal  and 
connections  within  (and  without)  the  team  on  his  producti 
programming  style  is  considered. 
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Suggestions  are  made  for  improvements  in  the  fields  of  programming 
Icnguage  design,  education  of  prcgrararaers,  programming  aptitude 
tests,  project  structure,  and  many  others  based  on  empirical 
psychological  data  and  studies  of  human  beings  and  their 
characteristics. 

The  author  expresses  some  of  the  spirit  of  the  book  in  his 
concluding  remarks,  when  he  expresses  the  hope  that  the  knowledge 
of  human  factors  involved  in  the  programming  task  and  systems  in 
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general  presented  in  the  hook  will  be  of  use  to  the  reader  in  his 
own  office,  project,  class,  or  other  programming  environment. 


WEINEERG72 

Weinberg,  G.K.;  The  Psycholcgy  of  Improved  Programming 

Performance;  Datamation  18,11  (November  1972)  pp. 82-85. 

In  this  article  Weinberg  reports  on  an  experiment  to  test  the 
impact  of  goals  on  programming  performance.  The  importance  of 
explicitly  stated  goals  is  stressed  by  noting  their  large  impact 
not  only  on  the  programs,  but  also  on  estimates.  Most  interesting 
and  useful  was  the  observation  that  "programs  built  under 
promptness  objectives  can  be  significantly  improved  in  almost  all 
other  objectives,  while  programs  built  under  minimum  core  or 
maximum  efficiency  tend  to  be  less  elastic."  Weinberg  concludes 
by  suggesting  the  adoption  of  an  * analy sis-coding-debugging- 
improving*  strategy. 


WEINEEBG75 

Weinberg,  G.M.,  Geller,  D.P«,  and  Plum,  T.  W-S;  IF-THEN-ELSE 
Considered  Harmful;  SIGPLAN  Notices  10,8  (August  1975)  pp. 34-44. 

The  authors  are  not  against  the  IF-THEN-ELSE  construct  in  all 
cases,  but  rather  the  unrestricted  nesting  of  the  control 
structure,  which  they  claim  can  lead  to  undesirable  programs.  The 
major  problem  with  IF-THEN-ELSE  logic  is  the  inability  of  the 
human  mind  to  understand  nested  constructs.  Thus,  the  authors 
advocate  the  use  of  replicated  forms,  giving  English  language 
examples  to  illustrate  their  point  that  regularity  allows  a  person 
to  understand  this  form  more  easily.  Three  replicated  forms  are 
suggested,  and  specific  examples  are  given.  The  article  stresses 
the  perils  of  a  one-to-one  translation  from  IF-THEN-ELSE 
constructs  to  replicated  forms,  claiming  that  the  'naturalness'  of 
the  form  must  be  exploited  in  order  to  derive  full  benefits. 


WEISSMAN71 

Weissman,  !.;  Software  Interfaces  for  Computer  Systems; 
Thesis,  University  of  Toronto,  Department  of  Computer  Sc 
(1971)  pp.1-71. 

Communication  between  program  modules  is  an  area  of  incre 
importance  and  interest  in  the  design  and  implementatio 
software  systems.  This  communication  is  handled  by  interf 
which  can  be  dealt  with  using  either  the  port  or  stru 
approach.  In  comparing  the  two  approaches  the  structure  app 
was  chosen  as  the  more  satisfactory.  Problems  exist  with 
structure  approach  primarily  because  modules  are  allowed  phy 
access  to  interface  structures.  In  an  attempt  to  solve  som 
the  problems  inherent  in  the  structure  approach,  an  inte 
system  has  been  built  for  handling  communication  between  pr 
modules.  The  interface  system  gives  the  modules  logical,  r 
than  physical,  access  to  interface  structures  and  regulates 
type  of  access  a  module  may  have  to  a  particular  structure. 
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interface  system  was  used  in  the  design  and  implementation  of  an 
informaticn  retrieval  system. 


WEILEB73 

Weller,  M.F.;  Eeport  of  Session  on  Transferability;  SIGPLAN 
Notices  8,9  (September  1973)  pp. 11-16. 


The 

Transf 
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report  discusses  two  aspects  of  portability  "Today's 
erability  Problems"  and  "Future  Systems  Design  for 
erability."  Short  discussions  are  given  on  the  following 
£  of  portability;  emulation,  standardization  and 

eration  of  an  operating  systems  interface  as  an  abstract 
e.  Similarly  various  opinions  are  given  for  the  future 
to  improve  portability  such  as  extensible  languages, 
ing  flexibility  and  levels  of  transferability. 


WEiLS73 

Wells,  M.E.;  i^lgorithmic  Languages  and  Machine-Oriented  Tasks; 
Proceedings  of  the  IFIP/TC2  Conference  on  Machine-Oriented  High- 
Level  Languages  (^lugust  1973). 

The  author  summarizes  a  theme  of  the  paper  when  he  states  "This 
author  believes  that  there  is  much  less  that  is  peculiar  to 
systems  programming  than  many  people  believe."  He  argues  that  the 
term  high-level  should  imply  small,  algorithmic,  machine- 
independent  languages.  He  further  claims  that  the  attempt  to 
control  the  implementation  details  is  the  cause  of  implementation 
languages  being  massive  and  complex. 

To  solve  the  technical  difficulties  of  efficient  compilation,  he 
suggests  that  we  study  compiler  and  hardware  design  as  seperate 
problems.  Moreover,  we  should  restrict  ourselves  to  subsets  of 
algorithmic  languages  for  which  efficient  compilers  can  be 
written. 


WHEFLFE72 

Wheeler,  D. J. ;  Assessing  the  Complexity  of  Computer  Systems; 
Proceedings  of  IFIP  Congress  71  (1972)  pp. 541-544. 


WIETH71a  CE2 

Wirth,  N. ;  Program  Development  by  Stepwise  Eefinement;  CACM 
(April  1971)  pp. 221-227. 

Programming  is  usually  taught  by  examples.  Unfortunately  the 
not  usually  demonstrate  widely  applicable  techniques,  rather 
show  what  a  computer  can  do.  Wirth  proposes  a  better  meth 
teaching,  that  of  stepwise  refinement. 

Stepwise  refinement  is  intended  to  demonstrate  the  gr 
development  of  a  program.  As  an  example,  Wirth  takes  the 
queens  problem  and  applies  the  method.  First  the  probl 
stated  in  very  general  terms,  leaving  many  details  unspeci 
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The  problem  is  gradually  refined  by  filling  in  details  at  each 
succeeding  step.  ?.t  each  step  a  choice  is  made  as  to  the  best 
design  and  solution  for  that  level.  This  process  continues  until 
the  solution  is  expressible  in  a  programming  language. 


Wirth  concludes  that  this  method  successfully  splits  the  problem 
into  a  number  of  subtasks  at  each  step.  The  degree  of  modularity 
obtained  determines  the  ease  or  difficulty  of  the  problem.  This 
method  allows  one  to  express  the  problem  in  notation  that  is 
natural  to  the  problem,  until  the  notation  of  the  problem  becomes 
that  of  the  programming  language.  Each  step  requires  concise 
design  decisions  which  affect  the  final  solution. 


WIPTH71b  CE26,925 
Wirth,  N. ;  The  Programming  Language  Pascal;  Acta  Informatica  1 
(1975)  pp. 35-63. 

This  paper  describes  the  programming  language  Pascal  and  provides 
a  justification  for  its  creation.  Wirth  intended  the  language  as 
a  teaching  vehicle  and  as  a  tool  for  the  creation  of  large 
programs.  He  tried  to  keep  the  language  small,  systematic,  and 
efficient.  Pascal  introduced  several  novel  concepts  and  has 
inspired  several  other  languages  (see  [CLABK71]). 

In  style,  this  paper  is  like  the  Algol  60  report  but  unfortunately 
it  is  neither  as  clear  nor  as  complete.  See  [ HABEBMANN73 ]  for 
harsh  but  partially  justified  criticism. 


WIBTH71C  CP23,196 
Wirth,  N. ;  The  Design  of  a  PASCAL  Compiler;  Software  -  Practice 
and  Experience  1,4  (October/December  1971)  pp. 309-333. 


WIBTH73 

Wirth,  N;  Systematic  Programming:  an  Introduction;  Prentice- Hall , 
Inc.,  Englewood  Cliffs,  N.J.  (1973)  pp. 1-169. 

This  book  introduces  programming  as  the  art  or  technique  of  of 
constructing  algorithms  in  a  systematic  manner,  as  a  discipline  in 
its  own  right.  No  specific  area  of  application  is  emphasized. 
This  book  is  tailored  to  the  needs  of  people  who  view  a  course  on 
systematic  programming  as  a  (possibly  neglected)  part  of  basic 
mathematical  training.  Few  people  beside  Dijkstra  will  fail  to 
profit  from  reading  it. 


WIETH74 
Wirth,  N 
Computing 


;  On  the 
Surveys  6,4 


Composition  of  Well-Structured 
(December  1974)  pp. 247-259. 


Programs ; 


Wirth  laments  that  "the  same 
programmers  from  advancing  to 
obstacle  against  moving  from 
style.”  For  those  who  are 
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several  examples  illustrating  the  use  of  stepwise  refinement  to 
achieve  "well  structured  programs,"  The  use  of  different  levels 
of  abstraction  to  achieve  good  structure  is  advocated. 

Wirth  concludes  by  stating  that  the  use  of  FOETP^iN,  "an 
unstructured  language...  to  teach  programming  --  the  art  of 
systematically  developing  algorithms  --  can  no  longer  be  defended 
in  the  context  of  Computer  Science  education." 


WCLVEBT0N74 

Wolverton,  E.W.;  The  cost  of  developing  Large-Scale  Software;  IEEE 
Transactions  on  Computers  C-23,6  (June  1974)  pp. 615-636. 

This  paper  gives  a  short  precis  of  a  tremendous  quantity  of 
information  gathered  by  the  author  over  many  years  on  project  cost 
estimation.  What  is  presented  is  a  somewhat  formal  methodology  of 
ccst  estimation. 

The  methcdolcgy  is  based  on  a  matrix  scheme,  where  a  cell  of  the 
matrix  represents  the  cost  of  activity  of  a  particular  nature  at  a 
certain  phase  in  the  project.  The  various  phases  and  activities 
are  presented  explicitly  along  with  figures,  taken  from  projects 
the  author  has  taken  part  in,  citing  probable  costs. 

One  of  the  keys  to  the  estimation  of  cost,  the  author  claims,  is 
ccmparison  with  previous  projects.  A  data  base  containing  actual 
ccst  statistics  in  specified  areas  of  projects  isreccmmended  as  a 
valuable  tool. 

This  methodology  has  arisen  partially  because  of  the  stringent 
contract  specifications  that  (U.S.)  government  software  is 
produced  under.  The  government  is  very  ccncerned  about  ccst/time 
overruns  and  insists  on  highly  accurate  cost  estimation. 


W0CDGEE72  CR24,757 
Wccdger,  M. ;  On  Semantic  Levels  in  Programming;  Proceedings  of 
IFIP  Congress  71  (1972)  pp. 402-407. 

This  paper  discusses  the  recognition  of  levels  of  meaning  in 
relation  to  the  programming  of  a  solution  to  a  given  problem.  An 
analogy  with  the  "operating  manual"  of  a  machine  is  made  in  an 
attempt  to  expose  inadequacies  in  present  programming  practice. 
The  author  maintains  that  at  each  level  an  abstraction  of  a 
process  (whose  meaning  is  clear  without  reference  to  the  other 
levels)  must  be  made.  Finally,  he  argues  that  conventional 
programming  practices  tend  to  confuse  these  levels,  and  that 
subroutines  do  not  solve  the  problem. 


WCETMAN72  CE25,416 
Wcrtman,  D.E.;  A  Study  of  Language-Directed  Computer  Design; 
Technical  Report  20,  Computer  Systems  Research  Group,  University 
of  Toronto  (December  1972)  pp. 1-207, 
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Starting  with  a  "clean"  subset  of  PL/I,  the  author 
computer  to  implement  its  semantics  directly, 
analyzes/predicts  its  performance,  and  in  the  process 
tools  which  "could  also  be  used  by  the  programmer  to  eval 
performance  of  computers."  This  turns  out  to  be  the  ma j 
part  of  the  work,  because,  as  he  points  out,  "for  languag 
less  elegant  structure  the  design  problem  is  much  more  di 
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WDLF71a  CE23,011 
Wulf,  W.A.,  Bussell,  D.E.  ,  and  Habermann,  BLISS:  A  Language 
for  Systems  Programming;  Ci\CM  14,  12  (December  1971)  pp. 780-790. 


WDLF71b 

Wulf,  W.,  Geschke,  C.,  Wile,  D.,  and  Apperson,  J.  ;  Deflections  on 
a  Systems  Programming  Language;  SIGPLAN  Notices  6,9  (October  1971) 
pp. 42-49. 


W0LF72a 

Wulf,  W.A.;  The  GOTO  Controversy:  A  Case  Against  the  GOTO;  SIGPLAN 
Notices  7,  11  (November  1972)  pp. 63-69. 


WULF72h 

Wulf,  W.A.,  Hopkins,  M.E.,  Peterson,  W.W.,  and  Waite,  W.M.;  The 
GOTO  Controversy:  Rebuttals  and  Discussion;  SIGPLAN  Notices  7, 
11  (November  1972)  pp. 70-91. 


WDLF72C  CB24,717 
Wulf,  W.A.;  Programming  Without  The  GOTO;  Proceedings  of  IFIP 
Congress  71  (1972)  pp.4C8-413. 

In  this  article  the  author  explores  the  common  program 
constructions  and  shows  how  they  may  be  realized  without  goto 
statements.  He  then  describes  his  own  experience  with  the 
language  BLISS,  which  is  goto-less.  He  concludes  that: 

(1)  It  does  not  matter  whether  or  not  a  language  includes  the 
goto.  There  are  certain  types  of  control  flow  which  occur  in  real 
programs.  If  these  constructs  are  not  provided  then  gotos  should 
be  used  to  synthesize  them.  The  danger  of  gotos  is  that  the 
programmer  will  do  this  in  obscure  ways. 

(2)  The  advantage  in  eliminating  the  goto  is  that  these  same 
control  structures  will  appear  in  regular  and  well-defined  ways. 
Both  the  human  and  the  compiler  will  interpret  them  better. 


WULF73 

Wulf,  W.  ,  and  Shaw,  M.  ;  Global  Variables  Considered  Harmful; 
SIGPLJ^N  Notices  8,2  (February  1973)  pp. 28-34. 
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An  extension  of  Dijkstra's  arguments  against  GOTO*s  to  global 
variables  -  variables  defined  and  modified  over  large  portions  of 
text.  Argues  for  richer  methods  of  defining  variable  scope  than 
the  Algol  block-structured  approach.  E.g.,  one  should  be  able  to 
limit  access  to  stacks  and  pointers  to  push-pop  routines  only . 

The  authors  argue  that  (a)  keeping  track  cf  global  variables  is 
difficult,  and  (b)  global  variables  complicate  the  process  of 
figuring  out  what  a  program  segment,  whose  actions  depend  on  them, 
dees. 
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YCHE74 

Yohe,  J.M.;  An  Overview  of  Programming  Practices;  Computing 
Surveys  6,4  (December  1974)  pp. 221-245. 

According  to  the  author,  the  purpose  of  this  paper  is  to  outline 
something  of  the  nature  of  "good  programming."  Since 
communication  between  humans  is  just  as  important  as  communication 
with  the  computer,  the  concept  of  programming  entails  adequate 
documentation  and  certain  other  tasks  to  be  performed.  The  author 
divides  the  programming  process  into  nine  tasks  and  discusses  each 
of  them.  The  paper  is  directed  to  students  or  beginning 
programmers,  but  does  not  exclude  experienced  programmers. 

The  difference  between  coding  and  programming  is  stressed  early  on 
in  the  paper,  when  he  separates  their  two  functions  into  program 
writing  and  design  analysis.  The  author  later  concludes  that 
"coders  are  not  difficult  to  find,  but  a  truly  good  programmer 

is . " 


ZELK0WITZ74  CR27,034 
Zelkowitz,  M.V.,  and  Bail,  H.G.;  Optimization  of  Structured 
Programs;  Software  -  Practice  and  Experience  4,1  (January  1974) 
pp. 51-57. 

A  code  optimizer  for  a  procedure- oriented,  *goto-less*  language, 
SIMPL,  is  described.  The  characteristics  of  structured  programs 
are  used  to  eliminate  redundant  subexpressions  and  loop  invariant 
calculations.  However,  the  results  obtained  indicate  only  a 
slight  decrease  in  program  size  (no  compile-time  or  execution-time 
figures  are  presented) .  The  authors  list  possible  refinements  to 
the  optimizer;  they  also  suggest  that  perhaps  programs  written  in 
a  structured  programming  language  do  not  require  a  separate 
optimization  phase. 
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A.ERAMS70  CE20,828 
Abrams,  P.S.;  An  APL  Machine;  Clearinghouse,  D.S.  Department  of 
Commerce,  Springfield,  Virginia  (lebruary  1970)  pp. 1-204. 


AEEEN69 

Arden,  B.W.,  and  Eoettner,  D. ;  Measurement  and  Performance  of  a 
Multiprogramming  System;  Proceedings  ACM  Second  Symposium  on 
Operating  Systems  Principles  (October  1969)  pp. 130-146. 


EALZEE67  CE15,184 
Ealzer,  E.M.;  Dataless  Programming;  Proceedings  of  the  FJCC  31 
(1967)  pp. 535-544. 


EFINCH  HANSEN70  CE19,620 
Erinch  Hansen,  P.;  The  Nucleus  of  a  Multiprogramming  System;  CACM 
13,4  (April  1970)  pp . 238- 241 , 250 . 


EFCPHY70  CE20,231 
Erophy,  H.F. ;  Improving  Programming  Performance;  Australian 
Computer  Journal  2,2  (May  1970)  pp. 66-70. 


"The  purpose  of  this  paper 
human  element  of  this  man/m 
Erophy  discusses  ways  of 
opposed  to  building  bigger  and  better 
improvement,  he  suggests  t 
of  already  available  tools. 

Generalized  systems  are 
reprogramming  to  solve  a  var 

the  use  of  decision  logic  tables,  more  comments, 
variable  names,  better  documentation  cross 

the  program,  and  the  use  of  programming  teams  as 
utilizing  the  existing  tools  of  software 

development.  Finally,  standards  in  language,  data  structures, 
documentation,  etc.,  are  proposed  to  improve  communication  between 
different  programming  groups  and  to  improve  the  portability  of 
computer  software. 
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EDESTALL69a  CE17,495 
Eurstall,  E.M.;  Proving  Properties  of  Programs  by  Structural 
Induction;  The  Computer  Journal  12,  1  (February  1969)  pp. 41-48. 

This  paper  presents  the  technique  of  structural  induction  for 
proving  the  validity  of  the  type  of  programs  where  repetition  is 
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accomplished  by  recursion,  and 
The  author  considers  the  techniqu 
powerful  tool  which  is  easy  to 
in  ordinary  mathematical  terms  of 
The  technique  depends  on  the  str 
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general  fcr  anj  input  data. 
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ight  later  be  formalized  to  a  point  where 
computer  to  provide  mechanized  debugging 


The  main  aim  of  the  paper  is  to  suggest  some  syntactic  devices  for 
writing  programs  in  a  way  which  facilitates  the  derivation  of 
proofs  by  structural  induction.  The  form  of  these  proofs  would 
then  be  similar  to  that  of  the  corresponding  programs.  The  author 
believes  that  the  discipline  of  stating  theorems  and  devising 
proofs  will  greatly  improve  programming  education  and  practice. 


EUBST;^LL69b 

Eurstall,  E.M.,  Landin, 
Algebraic  Approach;  in 

4,  American 


P.J.;  Programs  and 
Meltzer,E.,  Michie,D 
Elsevier  Publishing  Co 


their  Proofs:  an 
(eds. ) ,  Machine 
(1969)  pp. 17-43. 
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EUXTON70 


Euxton,  J.K.,  and  Fandall,  B.  (ed.);  Software  Engine 
Techniques;  NATO  Scientific  Affairs  Division,  Brussels,  Be 
(1970)  pp. 1-164. 

This  publication  is  organized  in  two  parts:  first,  transcrip 
discussions  among  the  participants  of  the  conference;  and  se 
a  collection  of  working  papers  presented  at  the  conference, 
emphasis  throughout  is  on  the  technical  aspects  of  real  pro 
rather  than  theoretical  or  management  techniques. 
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Among  the  central  topics  of  discussion  are  software  qualit 
flexibility,  the  problems  of  large  program  des ign 
implementation,  and  software  engineering  education, 
interes-ting  highlights  are  the  discussion  of  the  Apollo 
program  from  the  computing  point  cf  view  and  the  findings  o 
in  their  "super  programmer"  experiment. 
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The  papers  examine  specific  problem  areas  including  portability, 
software  reliability  and  software  evaluation.  This  publication 
presents  an  excellent  summary  and  discussion  of  the  problems  of 
software  engineering.  The  following  papers  are  included: 

Aren,  J.D.;  Estimating  Resources  for  Large  Programming  Systems 
Erewn,  W.S.;  Software  Portability 
Dijkstra,  E.W.;  Structured  Programming 
Falkoff,  A.D. ;  Criteria  for  a  System  Design  Language 
Gctlieb,  C.C.,  and  MacEwan,  G.H.;  System  Evaluation  Tools 
Hopkins,  M.E.;  Computer  Aided  Software  Design 
Lang,  C.A.;  Languages  for  Writing  System  Programs 
Needham,  B.M.;  Software  Engineering  Techniques  and  Operating 
System  Design  and  Production 

Needham,  E.M.,  and  Aron,  J.D.;  Software  Engineering  and 
Computer  Science 

Schwartz,  J.D.;  Analyzing  Large-Scale  System  Development 
Teitleman,  W.;  Toward  a  Programiring  Laboratory 

Ulrich,  W.;  Design  of  a  High  Reliability  Continuous  Cperation 
System 


C0NSTANTINE68  CR14,168 
Constantine,  L.L. ;  The  Programming  Profession,  Programming  Theory, 
and  Programming  Education;  Computers  and  Automation  17,2  (February 
1968)  pp. 14-19. 


The  classic  challenge  of  programming  has  been  that  it  lacks  (1)  an 
ordered  body  of  knowledge,  (2)  active  interaction  between  the 
practitioners  in  the  field  and  that  body  of  knowledge  and  (3)  a 
systematic  educational  approach  for  imparting  that  knowledge  to 
new  entrants  in  the  field.  The  author  maintains  that  the  body  of 
knowledge  of  programming  exists,  but  not  in  an  integrated  form. 
He  proposes  two  theories  distinct  from  each  other,  the  theory  of 
programs  and  the  process  theory  of  programming. 
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CCNWAY63 

Conway,  M.E.;  Design  of  a  Separable  Transition 
CACM  8,7  (July  1963)  pp. 396-408. 


CE5,024 
Diagram  Compiler; 


-79- 


older  i^rticles 


CCNWAY68 

CcLway,  M.E.;  How  Do  Committees  Invent?;  Datamation  14,  4  (April 

1968)  pp. 29-32. 


CCEEAIC69  CR1 7,694 
Corbato,  F.J.;  PL/I  as  a  Tool  for  System  Programming;  Datamation 
15,5  (May  1969)  pp. 68-76. 

Ore  of  the  more  important  aspects  of  the  MULIICS  effort  was  the 
decision  to  use  PL/I  as  the  systems  implementation  language.  This 
paper  discusses  the  reasons  for  choosing  a  high  level  language  for 
systems  programming  and  the  reasons  why  PL/I  in  particular  was 
chosen  for  MULIICS.  The  difficulties  of  implementing  the  language 
and  some  of  the  evils  of  PL/I  in  such  an  environment  are 
discussed.  That  Honeywell  intends  to  make  the  system  commercially 
available  attests  to  either  the  correctness  of  their  assumptions 
or  extreme  perseverence  in  the  face  of  adversity. 


DIJKSTBA62  CE6,649 
Dijkstra,  E.W.;  Some  Meditations  on  Advanced  Programming; 
Proceedings  of  IFIP  Congress  1962  (1962)  pp. 535-538. 

In  this  paper  Dijkstra  reflects  on  several  topics.  He  reviews  the 
bad  architecture  of  past  machines  and  of  the  then  largely 
available  commercially-produced  machines.  He  points  out  that 
since  programming  is  eguivalent  to  machine  design,  programmers 
should  accept  the  responsibility  of  influencing  future  designs  by 
exploring  them  in  software.  ALGOL  60  is  mentioned  as  an  entity 
which  provoked  considerable  effort  in  translator  writing  and 
ccnsiderable  thought  about  programming  languages.  Puzzle-minded 
programming  is  criticized  in  favor  of  a  systematic  approach. 
Correctness,  reliability  and  their  demonstration  are  emphasized, 
Dijkstra  concludes  with  a  desire  to  see  a  symbiotic  craf tsman -and- 
his-tcols  relationship  develop. 
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CR9,006 

Programming  Considered  as  a  Human  Activity; 
IP  Congress  (1965)  pp. 213-217. 
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pro  aracDiLg  through  the  basic  pattern  of  human  understanding.  From 
this  attitude  he  criticizes  programming  to  date  and  describes  more 
natural  and  elegant  structures. 

Dijkstra  gives  a  clear  statement  of  successive  refinement  of  a 
probleff,  emphasizing  (1)  division  into  parts,  (2)  the  parts 
together  form  the  whole,  and  (3)  the  principle  of  non¬ 
interference.  Here  also  are  his  classic  arguments  for  program 
correctness  and  against  the  "GO-TO.”  He  proposes  four  desirable 
language  features  and  concludes  that  an  area  for  work  is  that  of 
the  ccmprcmises  of  efficency  against  convenience. 


DIJKS1EA65b  CE9,023 
Dijkstra,  E.W.;  Solution  of  a  Problem  in  Concurrent  Programming 
Control;  CACM  8,  9  (1965)  pp.569. 

This  paper  presents  an  algorithm  which  ensures  that  at  any  moment 
one  and  only  one  of  a  number  of  mainly  independent  sequential 
cyclic  processes  with  restricted  means  of  communications  with  each 
other  is  engaged  in  the  "critical  section"  of  its  cycle. 


DIJKSTEA68a 

Dijkstra,  E.W.;  Go  To  Statement  Considered  Harmful;  CACM  11,3 
(March  1968)  pp. 147-148. 

The  concept  of  independent  co-ordinates  with  which  to  describe  the 
progress  of  a  process  is  discussed.  Such  co-ordinates  cannot  be 
found  if  unstructured  control  transfers  are  allowed  in  programmin 
languages.  Suggestions  are  made  for  alternative  construction 
that  are  both  flexible  and  structure'"*  so  that  an  independent  co¬ 
ordinate  system  can  be  maintained. 


DIJKSTBA68b  CP,14,979 
Dijkstra,  E.W.;  The  Structure  of  the  "THE"  Multiprogramming 
System;  CACM  11,5  (May  1968)  pp. 341-346. 

The  design  of  the  T.H.E.  Multiprogramming  system  is  discussed  with 
an  emphasis  on  methodology.  The  basic  unit  in  this  system  is  a 
process  and  these  are  organized  on  hierrchical  levels  which  serve 
to  implement  independent  abstractions.  Program  correct  ness  and 
verification  are  briefly  discussed  and  a  short  appendix  gives  some 
explanation  of  semaphores  and  some  results  prevention  of 
deadlock. 


DIJKSIRA66C 

Dijkstra,  E.W.;  Co-operating  Sequential  Processes;  In  Genuys,  F. 
(ed.).  Programming  Languages,  Academic  Press  pp. 43-112. 

The  use  of  semaphores  in  mutual  exclur  on  and  process 
synchronization  is  discussed.  Techniques  for  j.  a plementing  co¬ 
operation  among  parallel  processes  are  examined  in  detail.  A  proof 
of  correctness  is  presented  for  the  message  interpreter  for  the 
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T.H.E.  System.  Finally,  the  Ear.kers  Algorithm  is  discussed  as  a 
means  of  preventing  deadlock. 


DIJKSTBA6ed  CE16,717 
Dijkstra,  F.W.;  A  Constructive  Approach  to  the  Problem  of  Program 
Correctness;  EIT  8,  3  (1968)  pp.  174-186. 


Dijkstra 
correctness 
techniques 
be  produced 
manner  that 


states  that  there  are  two  ways  to  establish  the 
of  a  program.  As  an  alternative  to  a  posteriori 
this  paper  proposes  that  a  priori  correct  programs  can 
by  controlling  the  process  of  program  generation  in  a 
is  demonstrated  on  a  simple  problem. 


EV;iNS70 

Evans,  D.J.  (ed.);  Software70 ;  Transcripta  Eooks  (1970)  pp. 1-197. 

This  book  is  the  report  of  a  conference  aimed  at  consolidating 
what  was  known  about  software.  Various  important  academic  and 
industrial  topics  were  highlighted.  The  following  papers  are 
included : 

Evans,  D.J.;  The  current  software  situation 

McMonigall,  J.P.;  Criteria  for  the  design  and  implementation 
of  application  packages  for  third-generation  computers 
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FL0YD67 

Floyd,  E.W.;  Assigning  Meanings  to  Programs;  Proceedings  of  a 
Symposium  in  Applied  Mathematics,  American  Mathematical  Society 
(1967)  pp. 19-32. 


Described  is  a  system  of  associating  propositions  in  a  first  order 
predicate  calculus  with  each  "arrow"  in  a  program  flowchart.  The 
propositions  are  used,  along  with  some  axiomis  presented  in  the 
paper,  to  prove  statements  about  the  properties  of  commands  in  a 
program.  The  author  deals  specifically  with  proving  claims  about 
the  ranges  of  variables  in  a  program.  Such  a  proof  could  then  be 
used  in  a  proof  of  program  correctness.  Also  dealt  with  is  a 
technique  of  proving  program  termination. 


This,  in  combination  with  a  paper  by  Burstall  [  E(JRSTALL72  ] , 
provides  a  strong  algebraic  system  for  proofs  of  programs.  It  is 
clear,  however,  that  the  author's  technique  is  rather  tedious  and 
may  not  be  of  great  value  in  proofs  of  large  programs. 
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G;^.INES69 

Gaines,  R.S.;  The  Debugging  of  Computer  Programs;  Ph.D.  Thesis, 
Princeton  University,  Department  of  Electrical  Engineering  (1969) 
pp . 1 - 1 69 . 


This  thesis  is  a  general  study  of  tools  and  techn 
debugging  programs,  and  the  design  of  compilers  and 
systems  to  facilitate  debugging.  It  includes  an  analys 
programming  process  to  identify  carefully  what  the  proble 
debugging  and  how  they  arise.  Based  on  this  anal 
fundamental  notions  that  underlie  most  debugging  a 
identified.  The  facilities  that  are  currently  aval 

programmers  using  batch  operating  systems  are  discussed 
number  of  new  ones  are  presented. 
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GCCD7C  CR2 

Good,  D.I.;  Toward  a  Man-Machine  System  for  Proving  Pr 
Correctness;  Ph.D.  Thesis,  University  of  Wisconsin,  Departme 
Computer  Science  (1970). 

The  problem  considered  is  the  realization  of  a  compute 
p rogram- proving  system  that  is  applicable  to  real  com 
programs.  The  inputs  to  the  system  are  a  program  an 
specifications  this  program  must  meet  in  order  to  be  correct 
the  program  actually  is  correct,  then  the  system  should  e 
prove  that  the  program  is  correct,  or  at  least  provide  assis 
so  that  proving  correctness  becomes  a  feasible  task  for  a  h 
If  the  program  is  not  correct,  the  system  should  assis 
locating  errors  in  the  program.  The  total  question  o 
practical  realization  of  proving  the  correctness  of  program 
considered  from  three  levels.  At  the  first  level,  a  simple 
that  can  describe  a  significant  class  of  real  program 
developed.  Based  on  this  model,  the  idea  of  a  result  of  a  pr 
is  formalized.  The  second  level  is  a  general  method  for  pr 
program  results,  the  inductive  assertion  method.  The  third 
is  the  realization  of  a  man-machine,  interactive  program  pr 
system  through  a  partial  automation  of  the  inductive  asse 
method . 
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GEISHMA.N70 
Grishman,  B . ; 
pp. 59-64. 


The  Debugging  System  "AIDS”;  Proc.  SJCC 


CB19,806 
36  (1970) 


HCA.EE69 

Hcare,  C.A.E. ;  An  Axiomatic  Basis  for  Computer 
12,10  (October  1969)  pp. 576-580. 


CB1 8,328 
Programming;  CACM 


Working  with  a  simple  set  of  operations  on  data  (integer  addition, 
subtraction,  and  multiplication),  Hcare  examines  various  axioms 
which  may  be  added  to  the  axioms  of  arithmetic  to  cover 
peculiarities  of  computer  operations,  using  overflow  as  an 
example.  He  then  introduces  an  axiom  to  deal  with  the  assignment 
operation,  and  two  rules  of  inference.  Using  these  axioms  and 
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inference  rules,  he  investigates  formal  statem 
made  about  sequential  operations  and  iteration 
example  of  the  application  of  the  rules  to 
(Eegrettably,  no  rule  is  proposed  for  a  condit 
which  would  complete  a  minimal  set  of  control 
paper  concludes  with  a  consideration  of  the  lim 
study,  particularly  the  lack  of  a  basis  for 
termination,  and  some  cogent  arguments  for  the 
using  formal  techniques  for  language  design  and 
correctness . 
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LCNDONTOa 

London,  E.I.;  Eibliography  on  Proving  the  Correctness  of 
Programs;  in  Meltzer,  E. ,  and  Michie,  L.  (ed.). 
Intelligence  5,  American  Elsevir  Publishing  Company,  Inc. 
ppT569-580T“ 


CR20,000 
Com  puter 
Machine 
(1970) 


LCNDOKlOb 

London,  E.L.;  Eibliography  on  Proving 
Programs  -  Addition  1;  University 
Computer  Science,  no.  104 


the 
of 

(December  1970) 


Correctness  of  Computer 
Wisconsin,  Department  of 

pp. 1-8. 


LONDON70C 
London,  E.L.; 
Examples;  EIT 


Proving  Programs  are  Correct: 
10,  2  (1  970)  pp.  168-182. 


Some 


CE2  1,040 
Techniques  and 


MAENICK70 
Madnick,  S. E . ; 


Design  Strategies  for  File 


MAC,TE-78  (October  1970)  pp. 1-106. 

This  report  exemplifies  the  idea  of 
n"  analysis  as  applied  to  the  ( 
basic  concepts  imposed  on  tl 
cept  for  the  top-most  user-ori( 
representation,  and  that  the 
and  retrieving  information  should  be  an 
activities  ranging  from  the  purely  logical  to  the  purely  physical. 
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is 

That 
considered  to 
the  items  are 
except  in  the 


viewed  as  a  named,  sequentially  organized  (virtual) 
is,  the  items  of  information  in  the  file  are 
be  assigned  to  sequential  ’’addresses."  The  fact  that 
(say)  related  by  a  tree  structure  is  of  no  interest 
top-most  user-oriented  level  of  the  system. 


M;^NNA69 

Manna,  Z. ;  The  Correctness  of  Programs;  Journal 
System  Sciences  3,2  (May  1969)  pp. 119-127. 


of 


CE17,722 
Computer  and 


This  paper  presents  formal  predicate  calculus  results  on  the 
correctness  and  equivalence  of  programs  in  terms  of  the 
satisfiability  (or  un satisfiability)  of  certain  first-order 
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formulas.  The  only  programs  considered  are  those  with  assignment 
statements  and  conditional  jumps.  Correctness  of  programs  depends 
on  their  termination  and  final  result,  as  does  the  eguivalence  of 
programs.  Theorems  are  presented  concisely  and  rigorously  along 
with  short  illustrative  examples, 

MCFAEi;^ND7C  CE21,223 
McFarland,  C.;  A  Language-oriented  Computer  Design;  Proceedings  of 
the  FJCC  37  (1970)  pp. 629-640. 

Difficulties  in  using  computers  are  often  the  result  of  poor 
system  design  or  a  mismatch  between  the  language  and  the  computer 
being  used.  It  is  the  responsibility  of  the  user  to  produce  a  good 
algorithm  for  solving  his  problems,  but  he  is  entitled  to  assume 
that  good  construction  in  a  higher  level  language  will  produce 
efficient  object  programs.  To  achieve  this  it  is  proposed  that 
hardware,  operating  systems,  and  primary  languages  all  be  designed 
together.  The  article  gives  an  example  of  a  language  (TPL)  and  a 
computer  system  (Hydra)  designed  in  this  manner. 


MCKEEMAN66 

McKeeman,  W.M;  An  /approach  to 


CE1 3,436 

Computer  Language  Design;  Stanford 
University,  Department  of  Computer  Science,  Technical  Eeport  CS48 
(August  1966)  pp. 1-124, 


The  major  responsibility  of  language  design  should  rest  with  the 
user.  In  order  to  reduce  the 
might  undertake,  implement 


language  which  contains 
tasks . 


the 


compiler  writing  task  tc  one  a  user 
an  extendable  compiler  for  a  kernel 
concepts  common  to  all  computing 


MCKEEMAN67 

McKeeman,  W.M.;  Language  Directed  Computer 
the  FJCC  31  (1967)  pp, 413-417. 


CE1 4,136 
Design;  Proceedings  of 


An  entertaining 
happen  if  we  had 
machine  rather 
author  complains 
less  reliable  a 
suggested  are:  1 
not  designing  m 
attendent  con vers 
any  word  in  th 
building  common  n 


article  which  begins  by  imagining  what  would 
tc  compile  on  a  computer  modelled  after  a  Turing 
than  on  one  modelled  after  a  desk  calculator.  The 
that  compilers  and  operating  systems  are  getting 
nd  more  expensive  to  produce.  Among  the  remedies 
)  making  hardware  designers  write  a  compiler;  2) 
achines  with  multiple  arithmetic  formats  and  the 
ion  problems;  3)  replacing  the  ability  tc  address 
e  machine  with  lexic-level  addressing;  and  4) 
eeds  (e.g,,  a  scanner)  into  the  hardware. 


"The  obvious  attack  for  programmers  and  hardware  people  together 
is  to  devise  a  language  which  reflects  what  we  want  to  do  and  how 
tc  do  it  (for  instance,  in  parallel)  and  machine  structures 
effective  in  handling  that  language.” 
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MCKEEMAN70  CR21,021 
McKeeman,  W.M.,  Horning,  J.J.,  and  Wortman,  D.E.;  A  Com piler 
Generator;  Prentice-Hall,  N.J.  (1970)  pp. 1-527. 

This  bock  teaches  the  theory  and  practice  of  compiler 
construction.  A  System/360  realization  of  the  tools  is  presented 
and  documented.  The  theory  section  gives  examples  of  translating 
expressions,  declarations,  and  control  structures,  emphasizing  the 
relationships  between  recognizing  and  attaching  meaning  to  program 
parts.  Theoretical  groundwork  is  laid  for  studying  formal 
solutions  to  the  recognition  process  (parsing) .  This  leads  into 
the  discussion  of  automatically  generating  parsers  using 
precedence  and  LR  (k)  techniques. 

The  practice  section  describes  both  the  language  XPL  and  the 
components  of  the  translator  writing  system.  The  components  XCOM 
(the  XPL  compiler) ,  ANALYZER  (the  parser  generator) ,  and  SKELETON 
(the  proto-compiler)  are  discussed  both  as  tools  for  building 
compilers  and  examples  of  concepts  described  in  the  theory 
section.  Finally,  the  interface  to  OS/360  is  described  in  the 
appendices. 


HILLS70  CR19,422 
Mills,  H.D.;  Syntax  Directed  Documentation  for  PL360;  CACM  13,4 
(April  1970)  pp. 216-222. 

Mills  has  developed  an  interactive  system  that  parses  a  PL360 
program,  paragraphs  it,  and  interactively  interrogates  the 
programmer  about  the  intention  of  each  main  syntactic  construct. 
This  attempts  to  ensure  that  every  source  line  is  well  documented. 
The  programmer's  responses  are  kept  in  an  online  program 
management  system.  This  system  can  subsequently  be  asked  about 
identifier  usage  and  the  purpose  of  certain  classes  of  actions. 
Primitive  text  retrieval  from  the  documentation  given  a  keyword 
may  also  be  done.  This  system  is  essentially  experimental. 
Hcwever  it  does  point  the  way  to  future  automated  documentation 
systems. 


NAUR63  CR4,540 
Naur,  P.  ;  Revised  Report  on  the  Algorithmic  Language  A.LGOL60;  CACM 
6,1  (1963)  pp.1-17. 

"The  report  gives  a  complete  defining  description  of  the 
international  algorithmic  language  ALGOL  60.  This  is  a  language 
suitable  for  expressing  a  large  class  of  numerical  processes  in  a 
form  sufficiently  concise  for  direct  automatic  translation  into 
the  language  of  programmed  automatic  computers"  (from  the  first 
paragraph) . 

This  is  a  classic  paper  of  computer  science.  It  introduces  the 
language  that  is  the  father  of  almost  all  later  languages.  It 
does  so  concisely  and  clearly.  "Of  particular  interest  are  its 
introduction  of  all  the  main  program  structuring  constructs,  the 
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simplicity  and  clarity  of  its  description,  rarely  equalled  and 
never  surpassed” (HCASE73a) . 


N;^U369a  CF19,420 

Naur,  P. ;  Programming  by  J^.ction  Clusters;  BIT  9,  3  (1969)  pp. 

250-256. 


N;^.UE69b 

Naur,  P. ,  and  Eandell,  E.  (ed.) ;  Software  Engineering;  NATO 
Scientific  Affairs  Division,  Brussels,  Belgium  (1969)  pp. 1-231. 

This  report  contains  summaries  of  discussions,  and  working  papers 
presented  at  a  Working  Conference  on  Software  Engineering.  Topics 
covered  are  the  design,  production,  distribution,  and  service  of 
software,  and  the  relation  of  software  to  hardware.  The  following 
papers  are  included: 

Berner,  E.W.;  Checklist  for  Planning  Software  System  Production 
Dijkstra,  E.W.;  Complexity  Controlled  by  Hierarchical  Ordering 
of  Function  and  Variability 

Gill,  S. ;  Thoughts  on  the  Sequence  of  Writing  Software 
Mcllroy,  M.D.;  Mass  Produced  Software  Components 
Pinkerton,  T.E.;  Performance  Monitoring  and  Systems  Evaluation 
Eandell,  E.T.;  Towards  a  Methodology  of  Computing  System 
Design 

Selig,  F.;  Documentation  Standards 


NE0MANN69 

Neumann,  P.G.;  The  Eole  of  Motherhood  on  the  Pop  Art 
Programming;  Proceedings  Second  ACM  Symposium  on  Oper 
Principles  (October  1969)  pp. 13-18. 

The  author  seeks  to  identify  the  reasons  why,  in 
Mother  has  told  us,  we  continue  tc  pay  no  more  than  1 
the  principles  of  good  system  design  and  i mplementati 
agrees  that  clarity  and  efficiency  are  important,  but 
anything  about  realizing  them.  Several  interesting 
the  use  of  higher-level  languages  are  included. 
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NIEVEEGELT7C  CE20,659 
Nievergelt,  J. ,  and  Inland,  M.I.;  Ecunce-and- Skip :  a  Technique  for 
Directing  the  Flow  of  Control  in  Programs;  The  Computer  Journal 
13,3  (August  1970)  pp. 261-262. 


The  bcunce-and-skip  technique  for  directing  the  flow 
block  structured  programs  was  developed  as  a  result 
for  alternatives  to  the  *go  to'  statement  which  was 
Dijkstra  in  1968  as  a  desirable  feature  of  high-leve 
languages.  This  method  is  regarded  by  the  authors  a 
way  tc  implement  all  of  the  common  control  stateme 
level  languages  as  well  as  a  tool  for  program  debugg 


cf  control  in 
of  the  search 
questioned  by 
1  programming 
s  an  efficient 
nts  of  high- 
ing. 
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Ecunce-and-skip  provides  the  user  with  two  options:  To  delay  the 
use  of  the  result  of  a  test  indefinitely,  cr  to  make  the  entry  and 
exit  of  BEGIN_END  blocks  conditional  upon  the  last  test  performed,, 


Each  test  performed  is  coded  as  either  neutral  (its  result  has 
already  been  used),  successful  or  unsuccessful.  This  indicator  is 
matched  to  a  list  of  permissible  settings  of  the  indicator 
associated  with  each  BEGIN  and  END.  Under  a  mismatch  condition 
control  is  prohibited  from  entering  through  a  given  BEGIN  and  thus 
it  ^i£s  the  block,  or  control  is  not  allowed  to  exit  through  a 
given  END  and  hence  it  bounces  and  positions  itself  just  after  the 
corresponding  BEGIN. 


OFGASS69 

Orgass,  F.J.,  and  Waite,  W.M.; 
System;  CA.CM  12,  9  (September 


A  Ease  for  a  Mobile 
1969)  pp. 507-510. 


CE1 8,260 
Programming 


PAENAS67 

Parnas,  D.I.,  and  Darringer,  J.A.  ;  SODAS 
System  Design;  Proceedings  of  the  FJCC  31 


CR14,055 

and  a  Methodology  for 
(1967)  pp. 449-474. 


SODAS  is  the  first  of  a  number  of  systems  which  attempt  to  combine 
simulation  with  design  and  implementation  in  an  effort  to  increase 
system  production  efficiency.  SODAS  allows  the  modules  of  the 
"object  system"  tc  be  specified  at  any  desired  level  of  detail  and 
ir.  a  number  of  different  languages,  and  provides  several 
advantages:  all  interfaces  are  completely  specified;  the 
"fracturing"  of  the  system  into  its  various  modules  is  shewn  to  be 
correct  or  incorrect  prior  to  implementation;  and  it  is  possible 
to  determine  at  the  outset  if  low-level  inefficiencies  imposed  by 
high-level  design  decisions  will  significantly  impact  the 
performance  of  the  resulting  system.  Parnas* s  system  has  several 
drawbacks  (compared  to,  say,  P.M.  Graham’s  D.E.S.):  primarily  the 
use  cf  several  different  languages  is  confusing,  particularly 
since  the  implementation  language  is  distinct  from  the  simulation 
language  (s)  . 


PCCLE69 


CR19,612 


Pccle,  P.C.,  and  Waite,  W.M.; 
Proceedings  of  ACM  Second 

Principles  (October  1969)  pp.  19-2 

The  authors  advocate  that  machine 
the  use  of  macros  rather  than 
principal  advantages:  1)  the 

extended:  there’s  no  need  to  des 

outset;  and  2)  optimization  m 
through  modification  cf  the  appro 


RICHARDS69 

Richards,  M.;  ECPL:  A  Tool  for 
Proceedings  of  the  SJCC  34  (1969) 


Machine-Independent  Software; 
Symposium  on  Operating  Systems 

4. 

independence  he  achieved  through 
compilers,  with  the  following 
abstract  machine  may  be  flexibly 
igc  a  "complete"  language  at  the 
ay  be  tailored  to  specific  needs, 
priate  macros. 


CR1 8,258 

Compiler  and  System  Writing; 
pp. 557-566 . 
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is  a  simplification  of  CPL  (Basic  CPL) 
writing  relatively  machine  independent 
ially  compilers.  The  most  important  ch 
age  is  its  simple  semantic  structure 
ized  object  machine”  which  makes  ECPL 
endent  and  easy  to  define  accurately, 
ess  (the  only  data  object  being 
mentation-defined  length)  and  has  a  wealth 
cl  flow  in  an  orderly  fashion.  The 

esting  discussion  of  the  advantages  of  typ 
some  general  comments  on  design  of  1 
mentation . 
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BCEEETS67 

Roberts,  K.V.;  The  Readability  of  Computer  Programs; 
Eulletin  10,4  (March  1967)  pp. 17-24. 


CR17,857 
Com  pute  r 


RCSS67 
Ross,  E. T. ; 
Proceedings 


CR20,013 

The  AED  Approach  to  Generalized  Computer  aided  Design; 
of  the  ACM  22nd  National  Conference  (1967)  pp. 367-385. 


POSS70 

Rcss,  D.T.;  Uniform 
Software  Engineering 
Press,  New  York  (1970) 


CR2 1,883 

Referents:  An  Essential  Property  for  a 

Language;  Software  Engineering  1,  Academic 
pp. 91-101. 


STEEL67 
Steel,  T.E 
in  Alt, 
(1967)  pp. 

With  such 
unif icatio 
problem 
character! 
of  ccmput 
systems  is 


CRI 3,91 9 

.;  Standards  for  Computers  and  Information  Processing; 
F.L.,  and  Rubinoff,  M.  (ed.).  Advances  in  Co mputers  8 
103-152. 

diversity  in  the  field  of  Computer  Science,  some  form  of 
n  must  be  taken.  Standardization  of  the  terminology, 
definition,  programming  languages,  communication 
sties  and  physical  (i.e.,  nonelectrical)  characteristics 
ers  and  informaticn  processing  devices,  equipment  and 
a  must. 


"The  present  chaos  in  programming  languages  is  so  bad  that 
often  compared  to  the  Tower  of  Eabel,  and  any  help  is 
having."  The  complexity  in  attempting  to  standardize  progra 
languages  -  an  almost  imposible  task  -  is  recognized, 
developments  and  accomplishments  in  the  universal  standardiz 
of  the  languages,  Algcl,  Fortran  and  Cobol,  are  related. 
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worth 
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Although  only  twelve  standards  were  produced 
work,  the  process  should  accelerate  rapidly 
surmise  is  correct.  One  should  see  real 
toward  the  creation  of  systematic  standards  to 
organization  now  prevalent,  particularly  i 
languages  area. 
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TUBSKI70 

Turski,  W.  (ed.);  The  Efficient  Production  of  Large  Programs; 
Polish  T^.cademy  of  Sciences  (1970)  pp.  1-130. 


W;^ITE70 
Waite ,  W. M. ; 
Journal  13,1 


Building  a  Mobile  Programming  System; 
(February  1970)  pp. 28-31. 


CPI  9,610 
The  Computer 


The  author  discusses  a  technique  which  he  believes  to  be 
fundamental  to  the  improvement  of  mobility  of  programming  systems. 
It  is  recognized  that  the  mobility  of  a  programming  system  and  the 
associated  application  programs  is  an  extremely  important  aspect 
whenever  a  user  upgrades  or  changes  his  equipment.  The  mobility 
of  systems  software  is  a  function  of  the  number  of  installations 
which  are  involved  and  in  general,  the  mobility  of  a  program  is 
completely  dependent  on  the  mobility  of  the  programming  system  it 
utilizes. 


The  technique  for  providing  mobility  is  based  on  the  concept  of  an 
§tstract  machine:  a  hypothetical  computer  ideal  for  a  particular 
task.  The  program  for  this  task  is  written  for  the  abstract 
machine  and  to  run  such  a  program  on  a  real  machine,  the  abstract 
machine  must  first  be  realized  in  some  way. 

The  author  concludes  the  article  by  discussing  both  the  advantages 
and  disadvantages  of  the  technique  of  abstract  machine  modelling 
and  points  out  that  the  system  has  proved  extremely  mobile  in 
practice,  having  been  implemented  in  less  than  one  man-week  on 
nine  different  occasions. 


WIETH68 
Wirth,  N. ; 
J.^CM  15, 


PL360,  Programming  Language  for 
1  (January  1968)  pp. 37-74. 


the  360 


CR1 4,506 
Compu  ters ; 


WCLFE69 
Wolfe ,  J. M . ; 
(J^pril  1969) 


Testing  for 
pp .67-72 . 


Programming  Aptitude;  Datamation  15,4 


YCUNGS70 

Youngs,  E.A.;  Error-Proneness 
University  of  North  Carolina 
Psychology  (1970)  pp. 1-147. 


In  Programming;  Ph.C.  Thesis, 
at  Chapel  Hill,  Department  of 


This  thesis  basically  describes  a  programming  experiment  to  study 
human  programming  errors  with  an  eye  towards  suggesting 
improvements  in  programming  languages  and  processors.  Although  no 
startling  facts  were  made  nor  strong  conclusions  reached,  this 
thesis  begins  to  develop  techniques  and  concepts  for  quantifying 
program  development.  The  thesis  is  rather  easy  to  read,  and  it  is 
interesting  to  see  how  he  codes  and  evaluates  data  on  programming 
errors . 
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